Eject

ob eject

It writes the generated runtime into your repository and hands it over permanently. The overlay is stripped, so the file is ordinary Compose — not Compose with Onebox labels you would then have to unpick — and your workloads are repointed at it with your comments intact.

--out chooses the destination. It defaults to a free name beside the project, so an existing file is stepped around rather than written over. An explicit --out that already exists is refused; --overwrite is the way past that.

Why the exit is a command

A tool that generates your runtime is asking for trust in proportion to how hard it is to leave. Making the exit a first-class, tested command is how that trust is earned rather than requested.

It also means you can inspect the real thing at any time without committing to anything:

ob preview          # print the generated runtime, change nothing
ob eject            # write it out and hand it over

What ejection does not touch

• Your data. Service volumes and workload volumes stay exactly where they are.
• The host layout. Releases, the journal, and supporting services under /var/lib/ob/<app> remain until you remove them.
• Foreign resources. Anything Onebox does not own evidence for is left alone.

Refusals

Code	Means
eject_destination_exists	An explicit --out path already exists; --overwrite replaces it
eject_nothing_to_do	Every workload already references a Compose file
eject_failed	The runtime could not be handed over

After ejecting

You own the Compose file, the container names, the routing labels, and the lifecycle. Onebox’s release staging, journal, drift detection, approval gating and rollback no longer apply to those workloads — that is the trade you have chosen, and it is the same trade you would have had if you had never adopted Onebox at all.

If you want to tear the application down instead of handing it over:

ob destroy

ob destroy keeps volumes unless you explicitly ask otherwise.