---
title: "Dogfooding Orbit on Orbit"
description: "Orbit deploys Orbit - what shipped because our own deploys hurt, and what that costs."
date: "2026-06-09"
tags: ["culture"]
canonical: "https://orbit-handbook.sitesmojo.com/blog/dogfooding-orbit-on-orbit/"
---

Orbit
deploys Orbit. It has since 0.2, and it is the best product decision we have
made - every papercut lands on us first, at our own 11pm.

## What shipped because it hurt us

**Verify tails the discarded release.** Our own API failed at verify one
Friday, and the logs vanished with the discarded release. The evidence of
*why* it failed died with it. Now `orbit logs --release <n>` reaches releases
that never went live - the failure keeps its black box.

**Exit code 2 for empty plans.** Our release pipeline redeployed on every
merge, including docs-only changes. A no-change deploy is not a failure, but
it is not a deploy either; now `orbit plan` exits 2 on "nothing to do" and CI
skips the rest of the job.

**`protect: true`.** One of us promoted to production believing the shell was
pointed at staging. The artifact was fine; the heart rate was not.
Protected environments came out of that afternoon: production always asks.

## The uncomfortable part

Dogfooding also means the failure modes are ours. The
[0.4 dry-run-by-default change](/blog/orbit-04-dry-run-diffs-by-default/)
exists because *we* fat-fingered an apply that a diff would have stopped. The
tool gets sharper exactly where we cut ourselves.

If you run Orbit and hit an edge we have not, that is what the
[troubleshooting page](/docs/troubleshooting/) is for - and if the page does
not cover it, it will after your bug report.