Support
By default a new deploy goes live as soon as it finishes building — and for Git apps, a push to your production branch goes live automatically. If you want a safety gate on every deploy, turn on Require manual promotion for the app. While it is on, each new build — whether it comes from an upload, the API, or a Git push — is created as a preview candidate that is not live. Your production version keeps serving until you promote the new build by hand.
Turn it on
Open the app, go to Settings, and switch on “Require manual promotion”. It is off by default, so existing apps are unchanged. Turning it off returns the app to the normal “deploys go live on build” behaviour.
What changes while it is on
- Git pushes to your production branch still build automatically, but the build lands as a not-live candidate instead of going live.
- Uploads and API deploys also default to not-live candidates.
- Your production URL is never changed by a build — only by an explicit promotion.
Promote a build to production
On the app’s Deploys list, find the version you want to make live, open its ⋮ (more) menu, and choose Promote to production. This is the same action used to roll back to an earlier version, so you can move production to any version that finished building.
Deploy one version live anyway
If manual promotion is on but you want a specific upload or API deploy to go live immediately, pass activate=true when you create it — an explicit value overrides the app policy for that one deploy:
POST /v1/applications/{uuid}/deploys # multipart, field "file" = your .zip
# form field:
activate=true # go live now, even though the app requires manual promotion
Set it via the API
The flag is an app setting, so you can toggle it with the update-application call:
PUT /v1/applications/{uuid}
Content-Type: application/json
{ "require_manual_promotion": true }
See also Deploy a preview, then promote it to production for the per-deploy version of this workflow.