Log inStart free

Releases & rollback

Every deploy, env change, volume or database attach, and rollback creates a numbered release with the exact image and config it ran.

aloof releases api
v4   failed      2026-10-13 09:12  deploy         ghcr.io/me/api:1.5
v3   active      2026-10-13 09:02  config change  ghcr.io/me/api:1.4
aloof rollback api        # previous release
aloof rollback api 2      # a specific one

Zero-downtime deploys: new instances start next to the old ones and must pass readiness (your HTTP health path, or any HTTP response) before traffic moves and the old ones stop. If a new instance fails readiness, it's removed, the release is marked failed, and the previous release keeps serving. Apps with a volume are single-writer, so their old instance stops first and there is a short gap.

Rollback redeploys an earlier release's image, env, plan, port, command, scale and health settings, without a rebuild (git builds are tagged per release; the last 20 images are kept). Volumes, database attachments and domains stay as they are now. Also available as POST /v1/apps/{name}/rollback, the rollback_app MCP tool, and Dashboard → app → Releases.

Self-healing deploys

On by default for every app, no setup needed (see Self-healing deploys to turn it off). For 5 minutes after each deploy or config change, the edge compares the new release with the previous one. If the new release's 5xx rate is more than 5 percentage points higher and more than double the previous release's, or its p95 latency is more than double and more than 500 ms slower, it is rolled back automatically to the previous release. The reason and the numbers are recorded on the release (aloof releases, the API, MCP and dashboard), in the app's events and in the audit log.

To avoid false alarms: both releases need at least 100 requests; at least 10 failing (or slow) requests from at least 3 different client IPs are required; 5xx on routes that were already failing before the deploy don't count; upstream timeouts and client disconnects don't count. With no baseline nothing is rolled back. Rollbacks are never auto-rolled back, each deploy gets at most one automatic rollback, and a newer deploy or deleting the app cancels it. The watch lives in the edge process, so an edge restart during the 5 minutes ends that watch. Turn it off per app with aloof self-heal <app> off or the set_self_heal MCP tool.