Deployments
Understand how code becomes a release and what each deployment status means.
A deployment records the source, configuration, and environment used to release a service. Saving service settings and deploying those settings are separate actions. For application code, commands, variables, and disk mounts, deploy after saving to apply the new configuration.
Start a deployment
Open the service and choose Manual Deploy → Deploy latest commit. To release a particular repository revision, choose Deploy a specific commit and provide its full commit SHA. Image-based services offer Deploy latest image. Cron jobs call these actions Manual Build because a successful build prepares the image for later scheduled runs.
You can also configure automatic deployments, use the public API, or deploy from the Openstead CLI.
Follow the release lifecycle
| Status | What is happening |
|---|---|
| Queued | The request is waiting for available build capacity or allowance |
| Preparing | Openstead is preparing the build and runtime resources |
| Cloning | The selected repository revision is being fetched |
| Building | Dependencies and application output are being built |
| Predeploy | The optional pre-deploy command is running |
| Deploying | The artifact is being released to the runtime |
| Checking | Openstead is checking that the new release is ready |
| Live | The release passed its required checks |
| Failed | The release could not complete; inspect the error and logs |
| Cancelled | Cancellation stopped the deployment |
| Superseded | A newer queued deployment replaced this request |
An unchanged artifact can be reused, so not every release performs every build phase. Static sites publish files; container services start application instances.
Understand configuration snapshots
Each deployment captures the relevant configuration and secrets when it is queued. Editing a variable while a build is running does not alter that deployment's captured value. Save the correction and start another deployment.
The Live deployment identifies what is serving. A newer failed deployment can appear above it in history while the previous release continues to serve. Inspect both deployment history and runtime status when diagnosing availability.
Concurrent changes
Openstead serializes deployments for a service. Workspace settings control whether a new deployment cancels the currently running deployment or waits for it. In both cases, a newer waiting deployment supersedes older waiting deployments so obsolete commits do not accumulate in the queue.
Build concurrency and included build minutes belong to the workspace. A queued message explains when builds are waiting for capacity or allowance. Repeatedly clicking deploy does not increase that capacity.
Release safely
Use health checks, keep database migrations compatible with the previous release, and verify an important user flow after the release becomes live. Failed builds and pre-deploy commands preserve the previous release. Runtime recovery can require attention if the new release or its restoration cannot become healthy; a rolling deployment is not an unconditional zero-downtime guarantee.
Use rollbacks to restore a previously successful artifact. Database contents and user uploads require their own recovery strategy.