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, 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 it avoids overwriting an existing file. An explicit --out that already exists is refused; --overwrite is the way past that.

Why the exit is a command

Because Onebox generates your runtime, leaving must be possible, so the exit is a tested command.

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/onebox/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. If you operate those workloads outside Onebox, its release staging, journal, drift detection, approval gating and rollback no longer apply to them.

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

ob destroy

ob destroy keeps volumes unless you explicitly ask otherwise. When an active release exists, Onebox tears it down with that release’s recorded project snapshot and interpolation environment. A newer project file can therefore migrate a Compose-defined database to a managed service without making the old release impossible to parse during teardown.