Orbit Handbook
MarkdownOpen in ClaudeOpen in ChatGPT

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.

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 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

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.