Zero-downtime deploys and instant rollbacks
The exact sequence Aloof follows on every deploy, what happens when something fails at each step, and how rollback avoids a rebuild.
A deploy should either fully succeed or change nothing. Here's the sequence Aloof runs on every release, and the failure behaviour at each step.
The sequence
- Release record: a new numbered release is created with the full config (image, env, plan, scale, health).
- Build: pull the image with your registry credentials, or fetch git or the uploaded context and build it. On failure the release is marked failed and nothing running is touched.
- Release command: if configured, it runs once in a one-off machine. A non-zero exit fails the release, and old instances keep serving.
- Start new instances: each must pass readiness (your HTTP health path, or any non-5xx response) before it's marked running. Only running instances receive traffic from the edge.
- Cut over: the old instances stop only after all new ones are ready. If any new instance fails readiness, the new ones are removed and the previous release keeps serving, with no downtime.
One deliberate exception: apps with a volume are single-writer. Two instances must never mount the same data, so the old instance stops before the new one starts. Expect a brief gap for those apps.
Rollback without a rebuild
$ aloof releases api v7 active 2026-10-13 14:02 deploy paas/api:r1791... v6 superseded 2026-10-13 11:40 deploy paas/api:r1791... $ aloof rollback api 6
Each release stores its image reference and config. Rolling back redeploys that image with that release's env, plan, port, command, scale and health settings through the same readiness-gated sequence, so a rollback is also zero-downtime. Volumes, database attachments and domains are left as they are. The last 20 release images are kept.
What "zero-downtime" doesn't cover
- Database migrations that break the old release: use expand/contract migrations so old and new code both work during the cutover.
- Long-lived connections (WebSockets) on stopped instances are closed and must reconnect.
- Canary and blue-green strategies are accepted in aloof.toml but currently run as rolling deploys.