Skip to content
pilots
Dashboard

Ask your agent to deploy, and the whole app goes live with nothing for you to configure. Ask for a computer, and a sandbox is ready in less than half a second. Whatever sits idle sleeps, uses no compute, and is back just as fast with every program where it was.

Add Pilots to your agent Read the docs
you ask, your agent deploys

Deploy this app so that I have a live URL

I will use the pilots skill for this

Skill pilots

Bash pilot deploy

checkout built bld_5e0c2a7f

checkout release rel_91d4b3e6 accepted

Live https://checkout.pilotrun.app

Deployed to production

Deploy anything by asking

Your agent works out what your app needs and deploys all of it. The web server, the database, the background jobs, whatever the app contains.

Nothing to configure

Pilots recognises the framework, and your agent writes down the rest. You are not asked for a Dockerfile or a settings file.

Never a broken release

A new version takes over only after it answers. Until then the old one keeps serving.

The whole app

The web server, the database and the background jobs go live together, at an address on pilotrun.app.

How a deploy works →

Everything a production app needs

What you deploy is a production service. It comes with what you expect from a platform, and none of it is an extra to set up.

Push to deploy

Connect a repository once, and every push deploys itself.

A preview for every pull request

Each pull request gets an address of its own, and is removed when it merges.

Rollback

Put the previous version back in one command, with nothing to rebuild.

Your own domain

Point your domain at Pilots and a certificate is issued for it.

More copies when it is busy

Copies start when the app is busy and stop when it is quiet.

Databases with backups

Postgres with daily snapshots and recovery to a moment you choose. You operate it.

Scheduled jobs

A job runs on a schedule, waking the app to do its work.

Secrets

Secret values are sealed on the way in, and no command shows them again.

Logs and metrics

Read the logs of every copy from one command, and see what each is using.

How services work →

It sleeps when nobody is using it

An app with no visitors goes to sleep and uses no compute. The next visitor wakes it, and every program is where it was.

352ms wake of a real site through its public address, median, network removed

A visitor who arrives while it sleeps waits a moment and gets the page. They never see a loading screen or an error. Keep a copy awake when something needs it to be.

Most apps are idle most of the time. A staging copy, an internal tool, a side project.

And a sandbox, when you need a computer

A sandbox is separate from your deployed app. It is a small Linux computer with root access, for you or your agent to use for anything. Nothing boots, so it is ready in milliseconds. It sleeps after 2s of quiet.

468ms create, median on metal
302ms wake, median on metal
403ms checkpoint resume gap, median on metal

Measured on the production fleet. Hover any number to see where it came from.

Let an agent loose

Run it with its permission prompts off. The worst it can break is a computer you throw away.

Test like a crowd

Start a fleet and have each one use your product in a real browser, the way a person would.

Run code nobody has read

Every sandbox is a virtual machine of its own, walled off from every other.

What a sandbox can do →

Undo anything in a sandbox, exactly

Take a checkpoint before a risky step. A restore puts the whole sandbox back, running programs included.

checkpoint, break it, come back 
$ pilot machine checkpoint my-app --comment pre-upgradeID           SEQ  DURABLEck-3a3077f4  2    false$ pilot exec my-app -- ./upgrade.shSegmentation fault$ pilot machine restore ck-3a3077f4NAME    STATE    CREATED  URLmy-app  running  2h ago   https://my-app.pilotrun.app

The same computer comes back

Same name, same address. Nothing that was talking to it has to find it again.

Branch from any moment

A fork starts a new computer from a checkpoint, so you can try two answers from one starting point.

From sandbox to production in one command

When something you built in a sandbox turns out to matter, promote it. Nothing is rebuilt, and it becomes a production service with everything listed above. Try it below.

bold-otter.pilotrun.app sandbox
state
running
autoStop
suspend
minRunning
0
replicas
one
checkpoints
0

A simulation of the lifecycle, not a live computer. The states, knobs, and transitions are the real ones.

transcript
  1. create computer created from template, URL assigned
URL changes 0 across 0 lifecycle events

Your CI, on a fresh machine per job

Change one line in a GitHub Actions workflow and each job runs on Pilots, on a machine of its own that is deleted when the job ends. Nothing waits warm between jobs.

.github/workflows/ci.yml 
jobs:
  test:
    runs-on: pilots
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Private repositories too

A job that runs here uses none of your GitHub Actions minutes.

The tools are already there

Node, Bun, Go, Python and the Playwright browsers come installed, and a step can add anything else.

How runners work, and what they cost →

Building a product on top?

Give every one of your users a computer of their own. It sleeps when they leave and is back when they return.

Pilots for platforms

Three steps to a live app

  1. Install Pilots

    One small program, for Linux and macOS.

    curl -fsSL https://pilots.run/install.sh | sh

  2. Add it to your agent

    Claude Code, Cursor, Codex, Copilot and the rest.

    pilot mcp install claude-code

  3. Ask

    Your agent does the rest and hands you the URL.

    deploy this app

Pilots is open by invitation for now. Ask for one on Discord (opens in a new tab).