Why Pilots?
Most computers are idle most of the time. A staging copy, an internal tool, a sandbox an agent left an hour ago. Pilots is built so that an idle computer uses nothing, and comes back before anyone notices it was gone.
Asleep uses nothing, and waking is not a wait
Those two pull against each other and both have to hold. A wake that is cheap because it is slow has failed. A wake that is fast because the computer never really slept has failed too.
A suspended computer leaves no process, no reserved memory and no network interface on its host. By default it is frozen with its memory after 60s of quiet, and a request that arrives while it sleeps is held while it wakes, never answered with a waiting page.
The experiment and production are the same computer
Work usually starts in one place and ships from another, and the move between them is where an afternoon goes. Here there is no move. A sandbox running your image is promoted where it stands.
$ pilot promote my-shopSERVICE URL IDmy-shop https://my-shop.pilotrun.app svc_7c1e94a0same address, now a production serviceNothing is rebuilt
The computer becomes the first replica of the service. It gains releases, a health gate and rollback, and nothing is copied on the way.
The address does not move
Every link anybody shared while it was a sandbox goes on working, which is the reason this exists and a copy with a redirect does not.
One CLI for both
The command that created the sandbox is the command that deploys, scales and rolls back the service it became.
A sandbox is a whole computer
It runs Linux with a kernel of its own and gives you root, so it is for whatever a computer is for.
An agent with its prompts off
Let an agent run without asking permission for each step. Code that is unsafe on your laptop is safe on a computer you will throw away.
A fleet of users
Start many computers and have each one drive a real browser through your product the way a person would, then report what broke.
A load test that reads the page
The same fleet puts the product under every one of them at once, so you learn how it behaves when they all arrive together.
Code nobody has read
Run a dependency, a script or a pull request from a stranger behind a kernel of its own, where the worst outcome is a computer you discard.
Nothing is tied to one host
Object storage is the truth for every disk, and a host's own disk is a cache in front of it. Wipe any host and nothing is lost. Stop one below and watch where its computers go.
- bold-otter
- quiet-finch
- lucky-moth
- plain-heron
- brisk-vole
- north-elk
All hosts healthy. Kill one and its computers return on the survivors, same URLs.
A computer wakes on the host it slept on. When that host is gone, it is restored on another, with the same name and the same address. A computer whose host dies while it is running is rebuilt on a survivor.
There is nothing in the middle to be down either. Every host runs the same stack and serves the whole API, so a call about your computer works on a host that has never run it.
Built to be operated by an agent
You ask, and your app goes from a prompt to a live URL with nothing in between for you to do. That only works when the agent can do every step itself, so every operation is a command, and every command is offered over MCP except the few where a secret would pass through the model.
The dashboard is a window and never the only door. What it shows, the CLI can do, and an agent can do the same.
Read what Pilots is, see how it compares, or install the CLI and try it.