Deploy and roll back

Redeploy to release the current source and configuration. Roll back to reuse an earlier image, or restart when only the running process needs replacing. Rollback uses today’s variables, so it does not undo a configuration change.

Before you start

Choose the service and environment you intend to change.
Review its current variables, especially before rollback.
Allow an interruption if the service mounts a volume: its old container must stop before the new one starts.
For MCP, use a product-scoped token with Deployment write access for these actions and read access for history and logs.

1. Choose the operation

Action	Product App	MCP	Effect
Redeploy	Redeploy on the service panel	`deployment_service_redeploy`	New release from current source and variables; repository sources build again
Restart	Settings → Operations → Restart service	`deployment_service_restart`	Same image, no build and no new deployment history entry
Rollback	Select an earlier release in Service → Deployments	`deployment_service_rollback`	New release using the earlier image and current variables
Cancel	In-progress row in Service → Deployments	`deployment_deployment_cancel`	Stops the build or rollout; records a failed deployment with a cancellation reason

Only one deploy per service can be in progress. A second is refused rather than queued. Cancel the first if you intend to replace it; you cannot cancel an active or already finished deployment.

2. Start the release

For a redeploy, choose Redeploy after saving configuration changes. No new commit is required.

For rollback, list history with deployment_deployment_list, then select a target in Active, Replaced or Crashed status that has an image. A build that never produced an image cannot be a target. Supply the service and deployment IDs to the rollback tool.

If a variable change caused the failure, restore that value yourself before starting the release. Rollback does not restore database data. It creates a new history entry that identifies the selected earlier deployment; the original entry stays in place.

3. Follow the deployment

Open Service → Deployments and inspect the new row. The pipeline captures a source/configuration snapshot, resolves variable references, builds when needed, starts the runtime and waits for readiness.

Stage	Limit or behavior
Resolve variables	Missing references, cycles or an invalid secret reference fail before the build
Build	Repository image or static build; 30-minute deadline. Prebuilt images and rollbacks skip it.
Start and check readiness	Runtime releases have up to five minutes to become ready
Publish	Runtime traffic moves to the ready release. Static sites switch versions without container startup or checks.

Without a mounted volume, the previous runtime release serves while the replacement starts. With a volume, the old container stops first, causing a gap. Without a readiness probe, a started container counts as ready.

Verify it works

Check that the new deployment is Active, then exercise the service’s expected behavior through its active domain or a calling service. Confirm the intended commit or rollback target in the deployment record. The preceding active deployment becomes Replaced.

If it fails, read the reason and logs and events before trying another release.

Status	Meaning
`Initializing`	Accepted; capturing configuration
`Building`	Building an image or static files
`Deploying`	Starting and checking the release
`Active`	Current serving release
`Replaced`	Superseded by another release
`Crashed`	Previously active; restarted five times within five minutes
`Failed`	Did not become a serving release

Other deployment triggers

With automatic deployment enabled, pushes to a tracked branch deploy repository-backed services, including static sites. A runtime service at zero replicas also follows the sleep/push rules. Pull-request commits redeploy repository services in their preview. Forks deploy copied services with at least one replica. Uploading a new prebuilt static archive also deploys it.

Every build leaves a record of status, commit, output image and phase timings. Open its log from the deployment, or use deployment_build_list, deployment_build_get and deployment_build_logs.

Was this page helpful?