Restarting an App

A restart replaces the running instances of a Web Application or Background Worker with fresh ones. It does not rebuild your app, pull new code, or change any configuration — the same release comes back up, just in new instances.

What a rolling restart does

Restarts are rolling: the platform starts a replacement instance and stops an old one only once the replacement is ready, so with a Health Check Path set the app keeps serving throughout — even with a single instance. Without a health check, the rollout only requires the replacement to stay running for 10 seconds (web apps) or 30 seconds (workers); this does not prove the app can serve requests. See Health checks. A singleton app is the exception: its old instance stops before the new one starts, so it is briefly down.

When you need one

Most changes on the platform roll out on their own — a git push triggers a build and deployment, and a deployment already brings up fresh instances. Reach for a restart when the instances themselves are the problem:

• Picking up a deleted and re-created secret. Binding a secret or changing its value already rolls out new instances. Creating a replacement for a deleted secret does not; restart if an instance started while that secret was absent. See the secret lifecycle.
• Clearing bad in-memory state. A wedged connection pool, a memory leak, a stuck background job — a restart gives every instance a clean start.

A restart will not fix a broken build or bad code. If the app is failing because of what was deployed, fix the code and push again, or roll forward with a new deployment — see Deployments, Health Checks & Rollback.

Restart from the dashboard

1. In the dashboard, open your Organization, then the Project, then the Environment (for example acme → shop → production).
2. Open the app (for example web).
3. Click Restart and confirm.

Restarting requires deploy access. A stopped app (scaled to 0) can’t be restarted — scale it up instead. An app blocked for going over its monthly transfer allocation can’t be restarted either.

The app’s instance list updates as old instances are replaced by new ones.

Restart from the CLI

paas restart restarts the app you point it at with the usual context flags:

paas restart -o acme -p shop -e production -a web

Options:

• -o, --org, -p, --project, -e, --env, -a, --app — select the app to restart
• --json — print the raw API response instead of a table
• --host <HOST> — target a specific platform address (overrides PAAS_API_URL and the configured current host)

Watch the restart complete by listing the app’s instances:

paas ps -o acme -p shop -e production -a web

or check the app’s deployment status:

paas status -o acme -p shop -e production -a web

Restart vs. deploy

• Restart (paas restart): fresh instances of the current release. Use it to re-read secrets or clear state.
• Deploy (paas deploy): triggers a deployment of the app, applying whatever is currently configured. Use it when you changed what should be running, not just how it’s running.

Next steps

• Logs — confirm the app came back healthy after a restart
• Managing Secrets — automatic rollout and the re-created-secret exception
• Deployments, Health Checks & Rollback — when a restart isn’t enough
• Scaling & Autoscaling — run more instances, spread across servers