Skip to content
Onebox

Deploys you can read before they happen.

Onebox turns ob.yml into a sealed deployment plan for one Linux server. Review exactly what will change, approve it, then deploy over SSH — with health gates, rollback, and no agent on the host.

See a real deployInstall Onebox

Bring a Linux server with Docker. Onebox connects with SSH host-key verification and leaves no resident deployment agent behind.

plan → approve → deployob.yml · production
$ ob plan --out ob-plan.json
reading   ob.yml · production · [email protected]
state     r-0041 serving · no drift
 
~ shop-web-1       image   1.4.0 → 1.5.0
~ shop-web-2       image   1.4.0 → 1.5.0
+ shop-worker-1    new workload
! migrate          pre_release · data effect unknown
 
plan      sha256:9f21ab4c… · mode 0600 · expires 15m
risk      migration · strong confirmation required
 
$ ob approve --plan ob-plan.json --out ob-approval.json
type the release id to confirm: r-0042
 
$ ob deploy --plan ob-plan.json --approval ob-approval.json
staged    r-0042
migrate   provider atlas · 1 revision · changed=true
rolling   shop-web-1 … healthy
rolling   shop-web-2 … healthy
verified  checks/url 200 · X-App-Ready: yes
serving   r-0042 · r-0041 superseded

  • No host agent deploy over SSH

  • Verified host keys no trust-on-first-use

  • Expiring approvals bound to one exact plan

  • PostgreSQL PITR archived off-host

  • Apache-2.0 open source

How it works

Four commands, two artifacts.

Section titled “Four commands, two artifacts.”

The plan records what Onebox observed and what it intends to change. The approval binds to that exact plan. Both expire.

  1. ob validate — Declare

    Read the project file, resolve every shorthand, contact nothing.

  2. ob plan — Observe and propose

    Inspect the host, compare it to the declaration, and seal the result: the typed operation graph, exact config, host state, image digests and rendered Compose.

  3. ob approve — Confirm, locally

    A tamper-evident confirmation covering that plan, target, risk and expiry. Migrations use the strong ceremony, where the operator types back what the plan acts on — the release ID for a deploy, the job name for a job run.

  4. ob deploy — Execute under a lock

    Health-gated rollout, traffic drain, verification, then a versioned release with an explicit predecessor.

The authoring contract

You write the left. Onebox owns the right.

Section titled “You write the left. Onebox owns the right.”

Declare application intent instead of maintaining generated runtime. Turn fields on and watch Onebox derive names, networks, services, routing and storage.

  • shop-web-1 — the container, with a one-based replica ordinal that is never omitted

  • shop_default — the application’s own Compose network

  • onebox-proxy — non-root, socketless Traefik, plus an isolated discovery controller, routing and TLS

  • /var/lib/onebox/app — releases, current, journal and services

What it operates

One server, treated seriously.

Section titled “One server, treated seriously.”

Deployments, data and generated runtime share one evidence-backed lifecycle. Shipped vs proposed is the complete account.

  • Deploy safely

    Sealed plans, expiring approvals, health-gated rolling replacement, rollback, resume and abort.

  • Protect managed data

    Eleven service drivers with durable volumes and credentials. PostgreSQL adds continuous archiving, point-in-time restore and restore drills.

  • Control the host

    Locks and fencing, SOPS secret generations, scheduled jobs, and Traefik-managed routing and TLS.

  • Keep the runtime open

    Inspect generated Compose with ob preview, take ownership with ob eject, and automate through typed JSON or NDJSON output.

What it refuses

Refusing is the feature.

Section titled “Refusing is the feature.”

Onebox stops when it cannot preserve the meaning of your declaration. These are refusals, not warnings buried after a deploy.

  • at load

    A roll with nothing to gate on

    strategy: rolling with no health check. A rolling workload cannot publish a host port either, because two replicas cannot hold the same port during a roll.

  • at load

    A cron whose meaning would change

    A schedule Onebox cannot preserve exactly, rather than one approximated. A job that runs at nearly the right time is a job that ran at the wrong time.

  • at plan

    A promise it cannot keep

    A backup policy on a driver that cannot honour one, and a major version change a driver cannot perform in place — rather than replacing the container and leaving the data intact and unreachable.

Limits

The boundary is explicit.

Section titled “The boundary is explicit.”

Onebox is deliberately for one application on one host. These limits matter before you trust it with production.

  • Backups cover managed services, not workload volumes

    A service declaring backup — PostgreSQL today — is archived off-host and restorable to a point in time. A workload’s own volume is not, and ob doctor says so for every workload holding durable data.

  • mongodb runs a standalone server, not a replica set

    An application needing change streams or multi-document transactions will connect, authenticate, and then fail — in its own logs, not in anything Onebox says.

  • One host, and no failover

    Rolling deployment can avoid interruption while the box is healthy. It cannot make a failed physical host available. Recovery onto another host is a separate, evidence-backed workflow.

See every shipped and proposed capability, including what the schema accepts but cannot yet execute.

See the plan before the server changes.

Section titled “See the plan before the server changes.”

Install the CLI, scaffold ob.yml from the Compose file you already have, and inspect the first plan. Nothing deploys until you approve it.