What doesn't work yet

Single-tenant alpha. Public signup is closed.

One tenant, one operator, one host. There is no self-serve access, no billing, and no payment path. Signup stays shut until the three gates below are closed, each of which gets its own change record before it ships:

• kv: must exist or stop being advertised. See below.
• http mode must work under capability enforcement, or be refused at validation time. See below.

Closed 29 July 2026 — instance identity now comes from a minted secret. The broker used to identify a calling app by the source address of its connection. An address is a position, not a secret, and container addresses are recycled, so anything able to present a live instance's address inherited that instance's grants. A regression test extracted 200 Connection Established from a bare address claim before the fix, and is kept as the proof. Identity is now a per-instance token minted at start, stored only as a hash on the row whose deletion is the invalidation, and the address lookup was deleted outright rather than kept as a fallback — a fallback is the leak. ADR-0014 records the reversal, including the ADR-0008 sentence it makes false.

Capability enforcement covers job apps only.

Apps that run and exit — cron jobs, manual invocations — run on an isolated network whose only reachable peer is the capability broker. Every outbound call is checked against a granted capability and logged, allowed or denied.

http-mode apps do not yet run under that enforcement. The isolated network that blocks egress also cannot publish a port, so there is no path from the outside world to a long-running server on it. Closing this needs an in-network ingress relay, which is not built.

Until it is, the runtime refuses the combination at start with an explicit error. It does not silently fall back to an open network. A quiet downgrade — where you believe you have enforcement and do not — is the worst outcome available here, and we would rather fail your deploy than hand you that.

The remaining sharp edge: the manifest still accepts mode: "http", so the failure arrives at start rather than at validation. That is the third gate.

kv: is not implemented. Only fs: exists.

Our own documentation and our own MCP tool descriptions steer agents toward kv: as the durable default, because it is transactional and has no loss window. It does not exist yet. Only fs: — a real filesystem on a durable volume — is implemented.

This is the worst item on this page, because it is the one that actively misleads. An agent that follows our documentation writes an app that fails. It is being resolved in one direction or the other — implemented, or stripped from the docs and the tool descriptions in the same commit — before a second tenant exists.

Volume durability has a known loss window.

Apps hibernate to zero compute, which means the volume is the only state that survives being idle. Volumes are flushed on graceful stop and on a checkpoint interval — 60 seconds by default.

An ungraceful host loss discards writes since the last checkpoint. On the next wake the volume restores from the last good generation and the platform emits a volume.rollback event into the app's audit log. We do not roll back silently.

In particular: SQLite on fs: works and is genuinely useful, but its durability is the checkpoint interval, not fsync. If that distinction matters to your data, this is not yet the right home for it. The full reasoning, including the four alternatives we rejected, is in ADR-0013.

Wake latency was measured on a laptop, not on production hardware.

The numbers on the front page — p50 495 ms, p99 787 ms for a dependency-free Python app; p50 677 ms, p99 957 ms with a real dependency tree — are real measurements over genuine cold starts, not estimates. They were taken on an 8-core development machine running Docker Desktop on 29 July 2026.

Docker Desktop is not production. We already know that environment diverges from Linux in ways that produce real bugs: two defects found during development existed only because the published-port proxy accepts connections before the container behind it is listening. Expect these numbers to move — in either direction — when the alpha runs on real hardware, and expect us to publish the new ones next to the old.

Not measured at all, and therefore not claimed: behaviour under concurrency, wake latency with a large volume, cold-cache latency after a restart, and anything at all beyond 100,000 apps.