# How zero-downtime deploys and rollbacks work in 2026

Last updated: 2026-11-10

A zero-downtime deploy starts the new version next to the old one, checks that it answers, and only then moves traffic over. If the check fails, the old version never stops serving. A rollback is the same switch in reverse: traffic goes back to a build that already worked, ideally without building it again.

**Eurobase** and **Render** keep the old version serving until the new one passes its check, **Vercel** adds staged rollouts on its paid plans, **Fly.io** and **Kubernetes** let you pick the rollout pattern, and **Heroku** needs a feature called Preboot turned on per app. The part no platform solves for you is the database: a rollback restores code, not data.

## Deploy and rollback behavior at a glance

| Platform | How a new version goes live | Rollback | Gradual rollout |
|---|---|---|---|
| Eurobase | Serves your address only after it passes its check, otherwise the previous deployment keeps serving | To a recent successful deployment, without rebuilding | Not documented |
| Vercel | A deployment is promoted to production | Instant Rollback points your domains back to an earlier deployment | Rolling Releases on Pro and Enterprise, in stages you set |
| Render | The old instance keeps all traffic while the new one starts | Reuses the build artifact of a recent successful deploy | Not documented |
| Fly.io | Rolling by default, also immediate, canary or blue-green | Deploy the image of an earlier release again | Canary strategy checks one new machine first |
| Heroku | With Preboot, new web dynos start and get traffic before old ones stop | `heroku rollback` to a previous release | Not documented |
| Kubernetes | Rolling update, with 25% max unavailable and 25% max surge by default | `kubectl rollout undo`, 10 old revisions kept by default | Canary by running a second Deployment |

Behavior is taken from each provider's own documentation, checked on 10 November 2026.

## The release patterns

- **Recreate.** Stop the old version, start the new one. There's a gap where nothing answers. Fly.io's `immediate` strategy works like this.
- **Rolling.** Replace instances a few at a time. Kubernetes and Fly.io use this by default.
- **Blue-green.** Start a full copy of the new version beside the old one and switch all traffic when it's healthy. Fly.io's `bluegreen` strategy works this way, and so do platforms that point your domain at a new deployment in one step.
- **Canary.** Try the new version on a small part of the fleet or the traffic first. Fly.io boots one new machine, checks its health, then rolls on. Vercel's Rolling Releases send a share of visitors to the new deployment in stages, and the last stage is always 100%.

In every pattern except recreate, two versions overlap for a while, and both must work against the same database.

## What has to be true for a deploy to be invisible

- **A real readiness check.** The platform must know the new version works before sending users to it. A process that started isn't the same as a page that renders. Fly.io's smoke checks, for example, only watch for about 10 seconds that a machine doesn't keep crashing.
- **Old requests can finish.** Render switches traffic to the new instance, waits 60 seconds, then sends SIGTERM to the old one and waits up to 30 seconds by default before SIGKILL. Your app should stop taking new work on SIGTERM and finish what it has.
- **No local disk state.** Render turns off zero-downtime deploys for a service with a persistent disk. Keep state in a database or object storage.
- **Database changes that both versions accept.** More on this below. It's the most common reason a rollback makes things worse.
- **Clients that tolerate a version change.** A browser may hold JavaScript from the old build while the server runs the new one. Vercel recommends turning on Skew Protection with Rolling Releases for this reason.

## How Eurobase deploys and rolls back

Every push to a project's branch deploys that commit. The new deployment serves your address only after it passes its check, and if it fails, the previous deployment keeps serving. Only one deployment per project runs at a time, and pushes that arrive meanwhile each deploy after it.

The check depends on how the app runs:

- **Workers**, for Next.js, Astro, Nuxt and other frameworks on V8 isolates: before activation, Eurobase renders up to 16 concrete pages from the build, including `/`. Checks get 45 seconds in total and up to 10 seconds per response. A 5xx, a rendering error or an incomplete render stops activation and shows the route and reason.
- **Containers**: the deployment goes live only after your health path answers a GET with 2xx or 3xx. Eurobase requests it through your project's address up to 60 times, 2 seconds apart, with a 5-second timeout each. While an instance runs, the health path is requested every 30 seconds, and the instance stops getting traffic after 3 failures in a row.

From **Deployment history**, owners and admins can roll back to a recent successful deployment without rebuilding. A rollback doesn't count toward the daily deployment limit, which is 20 on Free, 100 on Starter and 500 on Pro. **Redeploy** builds the same commit again, and the Deploy Existing actions reuse an earlier build, both counting toward that limit. On Workers, a new deployment or a rollback starts with an empty response cache, so visitors don't get pages rendered by another version.

A coding agent with write access can also deploy and roll back through the MCP server.

- **Price:** a Free plan, then €10 or €20 a month + VAT for the workspace.
- **What it lacks:** preview deployments, so you can't test a branch on its own URL before merging, and a documented percentage rollout. There are no usage charges today: work over a limit is refused, apps on V8 isolates and Functions stop until the monthly reset, and containers and static sites keep serving. ISO 27001 and SOC 2 are still being worked toward.

## Rollbacks on other platforms

- **Vercel.** Instant Rollback points your domains back to a previous production deployment straight away. Hobby users can roll back only to the deployment right before, while Pro and Enterprise can pick any deployment that was on a production domain. Environment variables aren't updated during a rollback, and afterwards new pushes stop replacing production until you undo it.
- **Render.** A rollback starts a new deploy from the target's build artifact, so it's faster than a build. Rolling back in the dashboard turns off automatic deploys, but the API doesn't. How many artifacts are kept depends on your plan.
- **Fly.io.** Its rollback guide has you list earlier releases with `fly releases --image` and deploy the image you want again. Data changes stay as they are.
- **Railway.** A rollback goes back to the previous successful deployment and restores both its Docker image and its custom variables. Deployments older than your plan's retention can't be restored.
- **Heroku.** `heroku rollback` creates a new release that copies the slug or image and config vars of an earlier one. Release artifacts that are both older than 30 days and behind the 20 most recent releases are deleted, and those releases can't be rolled back to.
- **Scalingo.** Its rollback guide, last updated in 2017, describes pushing the last working commit again, which runs a normal deployment. It says rolling back to an earlier built image isn't publicly available.

## Why database changes break rollbacks

A rollback swaps code, never data. If the new version migrated data, the old code may no longer work with it, which Scalingo's guide warns about. On Eurobase, a Worker's SQLite database keeps the same data and schema for every deployment of the project, rollbacks included, and its migration files run once when a deployment activates.

Split risky schema changes over several deploys:

1. Add the new column or table, and keep the old one.
2. Deploy code that writes to both and reads the new one.
3. Copy the old data across.
4. Deploy code that no longer uses the old column.
5. Drop the old column only after you're sure you won't roll back past step 4.

Each step can be undone on its own.

## How to choose

- Pick **Eurobase** if you want every deploy gated by a render or health check and rollbacks from the deployment history on European infrastructure, and can live without previews.
- Pick **Vercel** if you need percentage-based rollouts and Instant Rollback, are on Pro or Enterprise, and a US provider is acceptable.
- Pick **Fly.io** or **Kubernetes** if you want to choose between rolling, canary and blue-green yourself.
- On **Heroku**, turn on Preboot if you haven't, or each deploy stops your web dynos before the new ones start.

For moving an existing app, see [Migrate from Vercel](/docs/guides/migrate-from-vercel), [Migrate from Render](/docs/guides/migrate-from-render) or [Migrate from Heroku](/docs/guides/migrate-from-heroku). For settings, read [environment variables and secrets](/i/environment-variables-and-secrets).

## Frequently asked questions

### What does zero-downtime deployment mean?

Users keep getting answers while you release, because traffic moves only to a version that's ready. A bug that passes the check still reaches users, which is what rollbacks are for.

### Is a rollback the same as redeploying an old commit?

No. A rollback reuses a build that already ran, so it's faster and skips a fresh dependency install. On Eurobase, Rollback serves an earlier deployment without rebuilding, while Redeploy builds again and counts toward the daily limit.

### Do environment variables roll back too?

It depends on the platform. Railway restores the custom variables of the target deployment and Heroku copies the config vars of the release you return to, while Vercel keeps the values the original build had and doesn't apply newer project settings. Check this before rolling back after a key rotation.

### Does a failed deploy take my site down?

On platforms that check before switching, no. On Eurobase and Render, a build or check that fails leaves the current version serving. With Fly.io's `immediate` strategy or a Heroku app without Preboot, a deploy can interrupt traffic.

## Sources

- [Vercel Instant Rollback](https://vercel.com/docs/instant-rollback) and [Vercel Rolling Releases](https://vercel.com/docs/rolling-releases)
- [Render deploys](https://render.com/docs/deploys) and [Render rollbacks](https://render.com/docs/rollbacks)
- [Fly.io deploy](https://fly.io/docs/launch/deploy/) and [Fly.io rollback guide](https://fly.io/docs/blueprints/rollback-guide/)
- [Heroku Preboot](https://devcenter.heroku.com/articles/preboot) and [Heroku releases](https://devcenter.heroku.com/articles/releases)
- [Railway deployment actions](https://docs.railway.com/deployments/deployment-actions)
- [Scalingo rollback](https://doc.scalingo.com/platform/app/rollback)
- [Kubernetes Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
- [Eurobase getting started](/docs/getting-started), [Workers](/docs/workers), [Containers and static sites](/docs/containers), [Cache](/docs/cache), [AI agents](/docs/agents) and [Plans and limits](/docs/plans)