Docs
Deployments & rollbacks
Immutable releases with zero-downtime promotion and one-click rollback.
Lifecycle
| Status | Meaning |
|---|---|
queued | Accepted; waiting for a build slot (per-plan concurrency). |
building | Cloning, installing, building the image or static output. |
deploying | Starting containers and waiting for health checks. |
ready | Serving traffic. The previous release is retired. |
failed | Something broke — the previous release keeps serving. See the diagnosis card. |
Failures never take your site down: promotion happens only after the new release passes health checks, so a broken deploy leaves the last good one serving.
Triggers
- Push — commits to the production branch deploy automatically (GitHub App).
- Manual — the Deploy button, per app, any branch.
- Rollback — re-deploys any previous successful release's commit.
- Image projects — redeploy on demand from the registered image.
Logs
Build and deploy logs stream live in the dashboard and are kept per deployment. Runtime logs stream from the running containers on the deployment page.
Build Doctor
Every failed deploy is diagnosed automatically. Instead of a wall of logs, you get a card naming the root cause and the fix — a missing module, an incompatible Node version, an out-of-sync lockfile, a crashing start command — and whether the fault is in the code or the platform. Coverage is effectively total; anything unrecognized still surfaces the failing log tail.
Per-app lineage
In multi-app projects each app has its own deployment history: promoting or rolling back one app never affects the others.