The sandbox and the service are the same machine.
Start one as a scratch pad for an agent to break. Promote it when it turns out to matter. It keeps its address, its state, and its identity, because nothing about it was ever temporary except your intentions.
Being built in the open, one phase at a time. See exactly where it is.
$ pilot create --template nodebold-otter.pilotrun.app$ pilot exec bold-otter -- npm testPASS test/checkout.test.js$ pilot checkpoint bold-otter --name greencheckpoint green (uploading in background)$ pilot promote bold-otterbold-otter.pilotrun.appsame address, now a production serviceA URL that outlives everything that happens to it
Most platforms mean "stable until you redeploy". On pilots the address is part of the machine's identity, so suspend, wake, checkpoint, restore, promote, and a host dying underneath it all leave the address alone. Drive one yourself and watch the counter.
- state
- running
- autoStop
- suspend
- minRunning
- 0
- replicas
- one
- checkpoints
- 0
A simulation of the state machine, not a live machine. The states, knobs, and transitions are the real ones.
- create machine created from template, URL assigned
Two things to want, one thing to run
A sandbox and a production service differ by a release, a health check and how many copies to run. Both suspend when idle and wake on the next request. They are not two products, and pilots does not build them as two.
Sandboxes
for agentsAn agent needs somewhere to run code it just wrote, and it needs that place to exist before the thought finishes. Restore from a template instead of booting, keep a checkpoint before every risky step, and roll back when the step goes wrong. The machine suspends itself when the agent stops typing and wakes on the next request, as a held connection rather than a loading page.
What agents get →Services
for productionPoint it at any Dockerfile and get a running service on a custom domain with a real certificate. Deploys are health-gated and keep the old release until the new one answers. Replicas start under load and stop when it passes.
What deploying looks like →Nothing boots, so nothing waits
A machine that boots takes as long as its operating system does, which is why sandbox products either keep you waiting or keep idle VMs burning money. pilots restores a memory snapshot instead, and pages it in lazily as the guest touches it, so a machine is answering before most of its memory has been read.
Those are the thresholds Phase 3 had to clear to close, measured on a laptop rather than on the metal this eventually runs on. Hover any number to see where it came from. When the Hetzner fleet is up, real fleet timings replace them here and these become the floor.
Lazy memory
A userfaultfd handler serves the guest's page faults straight out of a content-addressed blob, and replays the fault order recorded on the previous restore so the next one front-runs the guest. The alternative is one object-storage round trip per 4KiB page, which is not a slower design so much as a different product.
Lazy disk
The root disk is a read-through overlay: a template shared by every machine on the host underneath, the machine's own dirty blocks on top, and the bucket behind both. No machine holds a copy of its disk, and one that changed nothing stores nothing.
There is no control plane to lose
Every host runs the same three processes and serves the entire API, so no request needs a particular machine to be alive. State is a gossiped CRDT that every host holds a local replica of, which means a lookup is a read from local disk rather than a call to something that might be down. Kill a host below and watch where its machines go.
- bold-otter
- quiet-finch
- lucky-moth
- plain-heron
- brisk-vole
- north-elk
All hosts healthy. Kill one and its machines return on the survivors, same URLs.
Single writer
A host writes only rows about its own machines. Last-write-wins merges make a violation silent rather than loud, so this one is enforced in review.
Object storage is the truth
Local NVMe is a cache, for the root disk and the volume alike. The design test is that you can wipe any host's disk and lose nothing.
Adding a host
One script and an IP. It joins the gossip mesh and starts taking traffic. There is no scheduler to register with.
What it cannot do
-
Snapshots are locked to a CPU vendor
A memory snapshot carries raw CPUID, so it will not restore across the Intel/AMD boundary. The whole fleet has to be one vendor, and a machine cannot migrate off it.
-
Diff chains are exactly two levels
A template and a per-machine diff. A checkpoint of a checkpoint of a checkpoint is a hard error at parse time rather than a mystery at fault time.
-
One region
The design is decentralised but the fleet is not yet geographically spread. Multi-region comes after parity rather than inside it.
-
No production traffic yet
Phases 1 through 5 are closed and Phase 6, the product surface, is being built. The gate for calling it production is the full battery green on real hardware, and that has not happened.
WebJs is the framework, pilots is the platform
They are built by the same people, the way Next.js and Vercel are. You do not need either one to use the other: pilots runs any Dockerfile, and WebJs deploys anywhere a Node process runs. They are just designed by people who know what the other one does.
A WebJs app has no build step, so deploying one is copying files and starting a process. Its readiness endpoint is what pilots gates a health-checked cutover on.
Visit WebJs (opens in a new tab)Read it before you trust it
There is nothing to sign up for yet. What there is: the full design, written down, and the source that implements it. If the architecture does not convince you, the product should not either.