Deploying updates safely: zero downtime and rollback

Every DployHub app has one environment: the live app at https://<slug>.apps.dployhub.com, plus any custom domain you add. Every deploy, whether you click Deploy or push to GitHub, goes to that app. This page explains what makes that safe, and the habits that keep it that way.

What happens during a deploy

1. 1

   Build

   We build your code into an image using your build settings. If the build fails, nothing else happens: the running version is untouched and you get a Deploy failed alert.

2. 2

   Start beside the old version

   The new container starts next to the one serving traffic. Users still reach the old version.

3. 3

   Health check

   We call your health check path (by default /) until it answers with a success status, for up to 90 seconds. See Port and health checks.

4. 4

   Switch traffic

   Once the new version answers, traffic moves to it and the old container is removed. Its image is kept for rollback.

If the new version never answers, it is stopped, the deploy is marked failed with the reason and the last log lines, and the old version keeps serving. Users never see a half-started app.

Rolling back

We keep the last 5 built images for each app. If a release builds and starts but misbehaves, open the Deployments tab, pick an earlier successful version and click Roll back. It reuses the stored image, so there is no rebuild, and it goes through the same health-checked switch. See Roll back to a previous version.

Habits that catch problems early

• Run the app locally, or in CI, before you push to the deploy branch. Most failures show up there first.
• Protect the deploy branch on GitHub and merge through pull requests, so a reviewer sees each change.
• Set a real health check path, such as /health, that checks what your app needs to work. A version that cannot reach its database should not pass.
• Make database changes backwards compatible: add columns before the code uses them and remove old ones a release later, so a rollback still works.
• Hide unfinished features behind an environment variable flag and turn them on with a restart when ready.
• Watch the Logs and Metrics tabs for a few minutes after a deploy, and keep Deploy failed and App is down alerts on.

Need a test copy?

If you want a separate place to try changes, create a second app from the same repository on another branch, for example develop, with its own environment variables pointed at test services. It is an ordinary app with its own address and is billed like any other. Many small teams find the health check, rollback and a local run are enough.