OwnStack

Scaling processes

Scaling means changing how many containers a process type runs. Each container is fully isolated; web traffic is load-balanced across all web.N containers, queue workers all pull from the same queue. Scale changes are immediate — dokku spins up or shuts down containers to match.

Quick reference

$ ssh dokku@<stack-ip> ps:scale <app> web=2 worker=4
$ ssh dokku@<stack-ip> ps:report <app>
ownstack ps:scale is on the way

The first-class CLI command — and matching dashboard controls — are tracked in control-plane#294. Until then, use the ssh dokku@… form above.

Per-stack, not per-app

Scale is dokku state on each stack. If your app deploys to stacks A and B and you set worker=4 on A, B is unaffected. Either scale each stack to taste, or use the same numbers for active-active fairness.

Reading current scale

$ ssh dokku@<stack-ip> ps:report <app>
=====> <app> ps information
       Deployed:                      true
       Processes:                     6
       Running:                       true
       Status web 1:                  running (CID: abc12345)
       Status web 2:                  running (CID: def67890)
       Status worker 1:               running (CID: ghi34567)
       Status worker 2:               running (CID: jkl89012)
       Status worker 3:               running (CID: mno45678)
       Status worker 4:               running (CID: pqr01234)

Scaling and deploys

Scaling is independent of deploys — a ps:scale doesn't trigger a build. The new containers spin up from the currently-deployed image. If you scale up during a deploy, the new containers come from the deploying image (which might still be in flight). Practically, just don't scale during a deploy unless you have a reason.

The app.json formation gotcha

If your repo has an app.json with a formation block, dokku treats it as authoritative and refuses manual ps:scale:

!     App <app> contains an app.json file with a formations key
      and cannot be manually scaled

This is dokku's behavior; OwnStack passes the error through. Heroku interprets formation as initial defaults for review apps; dokku interprets it as a lock.

Two ways to unblock

OptionWhat to do
Remove formation from app.jsonThe cleanest if you're not actively using the formation defaults for Heroku review apps. After this lands and the app redeploys, manual scaling works.
Point dokku at a different fileKeep app.json for Heroku; create app.dokku.json without formation. Run ssh dokku@<stack-ip> app-json:set <app> appjson-path app.dokku.json. Dokku reads the formation-less variant; manual scaling works. Heroku is unaffected.
Don't try to "auto-strip" formation server-side

OwnStack used to consider rewriting DATABASE_URL / app.json on the host transparently. We decided against it: silently mutating app metadata that the app author committed is worse than surfacing the dokku error. Keep your repo as the source of truth.

Scaling to zero

$ ssh dokku@<stack-ip> ps:scale <app> web=0

Sets the count to zero — containers stop, the app returns 502 to anything reaching the stack on its hostname. Useful for maintenance windows. Bring it back with web=1.

Healthchecks during scale-up

New containers must pass healthchecks before serving traffic. By default this is a port-listening check on $PORT. If your app needs a longer warm-up, configure a custom healthcheck in app.json (checks.web) — see Healthchecks.