Deploys & rollback

Every time your service ships a new version, Helicarrier runs a zero-downtime rollout and records the result. This page explains what happens during a deploy and how to undo one.

The deploy pipeline

A deployment moves through clear states you can watch live:

1. Building — your image is built (or pulled, for image services).
2. Health check — a new container starts on an internal port and must pass a startup probe before it is trusted.
3. Traffic swap — once healthy, traffic moves to the new container and the old one is retired.
4. Active — the new version is live; the previous one becomes superseded.

Because the old version keeps serving until the new one is healthy, users never hit a gap. If the new version fails its health check, the rollout stops and the current version stays live.

Deployment history

The Deployments tab lists every deploy, newest first, with its status, trigger (manual, push, rollback), and — for git services — the commit SHA and message, linked to GitHub. This is your audit trail of what shipped and when.

One-click rollback

Made a bad deploy? Open a previous deployment and choose Rollback. Helicarrier redeploys that deployment’s already-built image — no rebuild — through the same zero-downtime path, so reverting is fast and safe.

Note

Rollback is available for deployments within the 7-day retention window. Helicarrier keeps each deploy’s image for 7 days; after that the image is reclaimed and that deployment no longer offers a rollback. To keep a version available longer, redeploy it (which makes it recent again).

Rollback is available for web-type services. Managed databases and cron services do not roll back this way — their state is handled separately (see Backups).

Auto-deploy

With auto-deploy enabled, a push to the connected branch runs this whole pipeline automatically. See Deploy from GitHub to turn it on.

Aborting a deploy

If a deploy is taking too long or you pushed by mistake, click Abort on the in-flight deployment in the Deployments tab. Aborting cancels the build in progress. Because a new version is built and health-checked on an internal port and only receives traffic once it’s healthy, aborting never takes your service down — the currently running version keeps serving throughout. Once a new version has already passed its health check and traffic has switched to it, there is nothing left to abort — the deploy is done.

Next

• Keep an eye on health with Runtime logs.
• Move configuration safely with environment groups.