---
title: "Shipped vs proposed"
summary: "The capability inventory: every capability marked shipped, schema-only, or intent-only, with what each means for someone relying on it."
description: "What the current binary does, what the schema accepts but cannot execute, and what is only declared intent."
status: shipped
read_when:
  - "Deciding whether to rely on a capability"
  - "Reconciling what the editor autocompletes with what the engine does"
  - "Explaining to someone what Onebox does not do yet"
---
Documentation says what is true today. Direction lives in the product statement,
and it is not presented as a capability.

This page is the reconciliation. Three states:

| State | Means |
| --- | --- |
| **Shipped** | The current binary does this. |
| **Schema only** | The loader validates it and it is in the published JSON Schema, so your editor completes it, but the behaviour is an open proposal. Declaring it changes nothing on the server. |
| **Intent only** | Validated and carried into plans, but the local engine runs nothing continuous for it. |

## Shipped

- An explicit `onebox.run/v1alpha2` Application schema. Each job runs one
  command; applications own their workflows and checkpoints.
- Compose generation and validation, SSH transport with known-host checking,
  state-bound plans, image pinning, rendered diffs.
- Scheduled jobs as host timers with exact cron translation, bounded retry
  inside one firing, one run record per activation in the host journal
  (`ob job history`, `ob job logs`, `ob status`), per-outcome
  notifications, and declared inputs for operator-initiated runs
  (`ob job run`).
- Per-workload reconciliation that retains proven-unchanged healthy workloads,
  health-gated rolling or recreate replacement for changed or uncertain ones,
  traffic drain, verification, versioned releases, retention, rollback. With
  the managed proxy, a roll retires a replica only after its replacement is
  published, and stops it only after the proxy has dropped it.
- Locks, fencing, append-only journals, resume, abort, migration gates, status,
  audit, SOPS secrets, supporting services, proxy operations, notifications.
- A canonical, versioned operation graph and one shared Go service for
  proposals, execution, structured events and operational memory. The CLI is an
  adapter over it. Observation is the engine's status snapshot, not a method on
  that service.
- Eleven supporting-service drivers, each running with a durable volume, a
  server-generated credential, and projected connection details. All but `nats`
  also run a health check; that image has no shell to probe with, so
  `condition: healthy` against it is refused at load.
- One application owner per host, recorded on the box at bootstrap and checked
  before every mutation, so a second application cannot converge over the first.
- Typed release manifests, durable activation and secret-rotation checkpoints,
  opaque secret generations, and retention that fails closed when the evidence
  it prunes against cannot be read.
- A closed CLI contract: a versioned envelope, an NDJSON event stream with one
  terminal record, three families of typed error code, and the 0/1/2 exit
  mapping. See [Policies](/docs/reference/policies) and
  [Error codes](/docs/reference/errors).
- Plan/status drift observation and plan-bound migration **backup reports
  validation**.

## Distribution, published by tag

Configured and verified in CI on every pull request, and published by pushing a
`vYYYY.M.REVISION-alpha` tag. What is installable at any moment is what
[the releases page](https://github.com/labstack/onebox/releases) lists; the
install commands work from the first published tag onward.

- Tag-gated GitHub Releases with checksum-covered Linux, macOS and Windows
  archives for amd64 and arm64, plus Debian and RPM packages for both Linux
  architectures.
- A Scoop bucket manifest for Windows amd64 and arm64, published only after the
  same release verification gate succeeds.
- A Homebrew Cask for macOS amd64 and arm64. Both macOS binaries are signed with
  LabStack's Developer ID and accepted by Apple's notarization service before
  publication.

## Distribution not shipped

WinGet, hosted APT and RPM repositories, non-macOS artifact signatures, SBOMs
and provenance attestations are not configured. The first release channels are
GitHub Releases, Homebrew and Scoop. Checksums detect corruption; macOS also has
Developer ID publisher identity and Apple notarization.

## Schema only

> **Your editor is ahead of the engine here**
>
> These three blocks are published in the JSON Schema and accepted by `ob validate`.
> Nothing behind them executes.

| Block | Reality today |
| --- | --- |
| [`backupTargets`](/docs/reference/fields/backup-targets) | Declaring a target creates no repository and no schedule. |

| [`externalServices`](/docs/reference/fields/external-services) | Connections are projected into the generated runtime, and two refusals are wired: an unknown `needs.env` part, and `condition: healthy` against a service with no probe. Health probes do not execute, and the remaining lifecycle refusals are not wired. |

Every [lifecycle failure code](/docs/reference/errors#lifecycle-failure-codes) is
raised by a path in the shipped binary, checked against the source in both
directions.

## Not owned at all

**Workload volumes.** A workload's own durable data is not copied anywhere.
`ob doctor` reports it for every workload holding some, so unprotected data is visible. Managed services are different: one declaring
`backup` is backed up continuously and recoverable to a point in time; see
the backup reference. Only the `postgres` driver has an executable contract
today; every other driver declares `policy_qualified: false` and its backup
policy is refused.

For PostgreSQL, the digest-pinned Onebox image carries the compatible WAL-G
executable. The host receives generated configuration only; no backup binary is
installed by Onebox.

**Restore proof.** `ob backup drill` proves it on demand: it recovers the
repository into a throwaway volume, waits for the cluster to promote, and makes
it answer a query: the same code a real restore runs, stopped before the last
step. What is *not* run is an unattended drill. Onebox puts no agent on the
host, so the timer from `drill.schedule` runs the archive-continuity check
instead, and the full proof is yours to run from CI on the cadence your policy
declares. No proof age is recorded, so nothing tells you the last drill has gone
stale.

**Log rotation.** Container logs are not bounded by Onebox today.

**High availability.** Rolling deployment can avoid interruption while the host
is healthy; it cannot make a failed host available. Recovery onto another host is
a distinct, evidence-backed workflow, not failover.

## Why the distinction is published

A product direction presented as a capability list can lead an operator to
believe their database is backed up before any backup has been taken.

A capability ships only when its design is agreed, its tests pass, and the
generated reference and this page are updated from proposed to implemented.
Until then it remains listed as proposed.