---
title: "What Onebox is"
summary: "What Onebox owns on the box, what stays yours, and the scope it refuses. Read before deciding whether it fits."
description: "The ownership boundary, the scope, and who this is for."
status: shipped
read_when:
  - "Deciding whether Onebox fits a project"
  - "Explaining to someone else what Onebox does and does not own"
---
Onebox is the production-operations layer for an application intentionally
running on one server. It supplies state-bound plans, exact approvals, locks, fencing, and durable
journals so a person or an agent can release, recover, and maintain the
application without assembling those operations from shell scripts.

## The ownership boundary

> You own your application containers. Onebox owns everything else on the box.

You provide and administer the Linux host, SSH access, and Docker installation.
Inside that boundary, Onebox owns the generated application runtime: the proxy,
TLS, networks, release staging, supporting data services, scheduled jobs, locks,
and the evidence needed to operate them safely.

That sentence states the direction. Owned today:

- host bootstrap and the container runtime check
- the proxy and its TLS
- the shared network
- release staging and retention
- supporting data services and their credentials
- PostgreSQL continuous archiving, point-in-time restore, and restore drills once
  `ob backup enable` has established protection
- scheduled jobs

**Not owned today:** host or Docker installation, workload-volume backups,
backup contracts for non-PostgreSQL drivers, unattended full recovery drills,
and log rotation.

> **Why the distinction matters**
>
> A declared backup policy is not protection. PostgreSQL becomes protected only
> after `ob backup enable` has installed the runtime, enabled continuous archiving,
> and taken the first base backup.

## Scope

One application per environment, on one active production host. That application
may have as many workloads as it needs (a server, workers, jobs, databases,
caches, a proxy) but the unit Onebox owns is the application, and a host runs
one of them.

`ob bootstrap` enforces this by writing an owner record
on the host, and every command that changes anything checks it first. Point a
second application at the same machine and it refuses before touching anything:

```
host is owned by application "shop"; application "blog" cannot mutate it
```

The record is released only when nothing of the application is left: volumes
removed, and the proxy removed too if this application manages it. Keeping it
while data survives lets you come back and run
`ob destroy --volumes`, and a host released early is one whose remaining volumes
its owner can no longer reach. `ob destroy` tells you which command releases it.
`ob preflight` reports the current owner, and passes on a host nobody has claimed
yet.

Onebox is **not**:

- a cluster manager, Kubernetes replacement, PaaS, or hosting provider
- a multi-host or multi-region orchestrator
- a way to run several independent applications side by side on one host
- a generic Docker dashboard, terminal, or remote shell
- a universal infrastructure-as-code language
- a guarantee of availability after losing the only host
- a guarantee that arbitrary migrations or external effects can be undone

## The interface is the CLI

The CLI is the product interface, for people and for agents.

There is no MCP surface. A read-only tool list constrains nothing when every
mutation goes through the CLI anyway and the agent can run `ob deploy` in a
shell; the boundary it appears to provide does not exist. Point an agent at the
`ob` binary the way you would point it at `git` or `gh`.

## Where to go next

- [Install](/docs/get-started/install), then [your first deploy](/docs/get-started/first-deploy).
- [The ownership boundary](/docs/concepts/ownership-boundary) explains why this
  framing drives the rest of the design.
- [Shipped vs proposed](/docs/reference/capabilities) lists the current capabilities.