Skip to main content

​
Choose the deployment contract

Use app releases to update managed application code and configuration within an existing workspace. Use image workflows for a frozen runtime environment. These have different recovery boundaries; see deployment strategy.

​
Prepare a release

Call Prepare an app release with source files, app configuration, a deployment scope, and an idempotency key according to the generated schema. Reuse the key only for the same logical attempt. Your backend must not let unrelated tenants claim another deployment’s scope or workspace. Poll Get an app release and display release logs while preparation runs. Keep failures visible; an HTTP acceptance response does not mean the app is live.

​
Activate and observe

When the release is ready, call Activate an app release, then continue observing its status and app health. Preserve the existing resource IDs and use the URL returned for the app rather than constructing one from a display name.

​
Recovery

List retained releases and expose only supported activation or rollback choices. App rollback restores code and configuration, not database contents. Handle a failed candidate as a deployment outcome; do not replace the workspace to hide the failure. For a working terminal workflow, follow stage and activate. For log delivery, see App Logs.