---
title: "Deployments"
description: "The release lifecycle: plan, diff, apply, verify, live - and why releases are immutable."
canonical: "https://orbit-handbook.sitesmojo.com/docs/deployments/"
---

# Deployments

What actually happens when you type `orbit deploy`.

## The release lifecycle

Every deploy moves through the same five stages, laptop or CI:

```text
plan -> diff -> apply -> verify -> live
```

1. **Plan.** Orbit compares `orbit.yaml` plus your artifact against what is
   currently running and produces a release plan.
2. **Diff.** The plan is printed as a diff - services added, config changed,
   routes moved. Since 0.4 this is always shown
   ([why we changed it](/blog/orbit-04-dry-run-diffs-by-default/)).
3. **Apply.** The new release is built out *alongside* the old one. Nothing
   the old release serves is touched.
4. **Verify.** Orbit polls your `health` endpoint until it passes, or gives
   up and discards the new release - your users never saw it.
5. **Live.** Traffic switches. The old release stays on disk, addressable,
   ready for [rollback](/docs/deployments/rollbacks/).

## Releases are immutable

A release is a sealed artifact plus its resolved config. Promotion between
environments moves the *same* release - what you tested in staging is
byte-for-byte what production runs.

## Read next

- [Rollbacks](/docs/deployments/rollbacks/) - undo in seconds
- [Zero-downtime](/docs/deployments/zero-downtime/) - how the switch works