v0.0.1

Ship only the build of your app that passed.

airlock starts local: run the gate with Bun in your own process, inspect the receipt, and keep a failed candidate from replacing the current build. When local is no longer enough, its Cloudflare backend is designed to be self-hosted in your account so bounded checks can run at the edge against a preview URL.

Written for a world where the push is as likely to come from an agent as from you: a green check is a claim, not a fact, so airlock never trusts it. It only trusts a signed proof, bound to the exact bytes it tested, checked on a URL nothing user-facing can reach.

This page is evidence for the Cloudflare path, not a claim that every local run gets edge isolation: it was deployed to a no-traffic preview URL, tested by two real terrarium checks in separate processes, admitted by an ed25519-signed proof, and promoted by hand. The default local backend remains in-process and unisolated.

View the signed receipt for this exact page

Read the docs
A lone operator before a colossal sealed airlock hatch, just beginning to open onto a calm horizon
a candidate, held until the door opens airlock

a small adjustment for agent-written code

One candidate build, from source to live traffic.

Start with the local gate and its explicit limits. When a project needs edge-hosted, bounded checks, self-host the Cloudflare backend in the same account as the preview. In either mode, a green check is only a claim: verify a signed proof bound to exact bytes before anything reaches user traffic.

This exact page shipped through steps 1, 2, 4, and 5 for real: a Worker deploy, a real isolated terrarium fanout, a real signed proof, a human promotion — view the signed receipt. Step 3's Durable Object path is now real too — deployed, and its isolation empirically proven, not just described — but narrower than shown: Workers block eval, so a check is one of a small fixed set of kinds today, not arbitrary code. See Fanout backends and the isolation-proof experiment.

A swarm of operators crossing a horizon toward a tall teal repository monolith
before airlock

Each push, one candidate.

airlock admits a candidate only after its proof verifies. Scheduling a swarm of pushes is outside this demo.

  1. Artifacts

    Source lands in an Artifacts repo. airlock names that tree by digest.

  2. Workers or Pages

    The candidate deploys to a preview URL. Tests fetch it; live traffic does not.

  3. Workflows / DO / Queues proven, narrower

    Checks fan out against the preview URL and join into one result. A real Durable-Object-per-check backend ships and is isolation-proven; on this page, terrarium did the fanout instead — both for real.

  4. Signed proof

    The result is signed with the digest inside it, then checked against trusted keys.

  5. Promotion gate

    If the proof verifies, the caller flips the flag for this candidate. If not, users stay on the current build.

after airlock live traffic, logs, analytics, traces, alerts

How to use it

Run it locally

Requires Bun. Three commands, no Cloudflare account and no keys. The last one runs the "napkin" — a rough sketch, not the finished build — which pushes two candidate builds: one whose tests pass and goes live, one with a failing test that gets blocked while the current build stays live. The docs cover the ports, proof verification, and the limits.