Zero-downtime deploys with instant rollbacks

Every Worker deploy on Benediction is versioned. The old version isn't destroyed — it's kept, ready to be promoted back the instant something looks wrong. This one design decision is why our teams deploy dozens of times a day without drama.

Deploys are metadata changes, not code swaps

When you run gitflare workers deploy, the code is uploaded once, hashed, and registered as a version. The deploy step then points your environment at that version. The propagation step is a fast metadata update across locations — which is why the CLI reports deployment in about a second and a half.

gitflare workers deploy ./src -e prod
# ✓ uploaded bundle 8f2a…e1
# ✓ registered as version 87
# ✓ prod now serving version 87 (previous: 86)

Rollbacks are one command

Because the previous version still exists, rolling back is just a pointer flip:

gitflare workers rollback my-worker --to 86
# ✓ prod now serving version 86
# ✓ retained versions: 80 … 87

No rebuild, no re-upload, no cold window. If the new version misbehaves, the old one is serving again within seconds — and it's the exact code that was serving before, byte for byte.

What makes a version rollback-safe

Two properties matter. First, code must be immutable once uploaded — a version never changes, only the pointer to it does. Second, state must live outside the code, in KV or durable storage, so rolling back the function doesn't strand data written by the new version. We keep both by design.

Rule of thumb: if a rollback is scary, the deploy wasn't actually reversible — and that's the problem to fix, not the rollback.

Staged rollouts for extra safety

For high-traffic Workers, stage the rollout instead of flipping at once. Route a small percentage of traffic to the new version, watch the error budget for a few minutes, then promote to 100%.

gitflare workers rollout my-worker --version 88 --percentage 5
# observe …
gitflare workers rollout my-worker --version 88 --percentage 100

The habit it builds

Teams that adopt versioned deploys stop treating releases as events. Deploys get smaller, more frequent, and more boring — which is exactly the point. Boring deploys are the goal; excitement belongs in the code review, not the production rollout.