---
title: "Zero-Downtime"
description: "Blue-green and rolling strategies, and how health checks gate every traffic switch."
canonical: "https://orbit-handbook.sitesmojo.com/docs/deployments/zero-downtime/"
---

# Zero-Downtime Deploys

Users should never notice a deploy. Orbit ships two strategies; both keep the
old release serving until the new one has proven itself.

## Blue-green (default)

The new release is built out completely beside the old one, verified against
your `health` endpoint, then traffic switches atomically.

```text
old release  ############# serving ############|
new release      build -> verify -> [switch] ->| serving
```

The switch is a router flip, not a restart - in-flight requests drain on the
old release while new ones land on the new. This is also what makes
[rollback](/docs/deployments/rollbacks/) instant: the old release is still
there, warm.

**Cost:** both releases run simultaneously for a short window. For most
services that is seconds of double capacity.

## Rolling

```yaml
release:
  strategy: rolling
```

Replicas are replaced one at a time, each verified before the next begins. Use
it when double capacity is not an option; the trade is a slower rollout and a
mixed-version window your service must tolerate.

## Health checks gate everything

Whatever the strategy, traffic only moves when `health.path` answers OK. A
release that never passes is discarded and the deploy fails **loudly** - a
failed deploy leaves production exactly as it was.