Skip to content
pilots
Dashboard
All pages

Quickstart

Install the CLI, sign in, run something in a sandbox, and put a directory on a URL. Nothing here needs a Dockerfile, a YAML file, or an account with a cloud provider.

Install the CLI

One static binary, no runtime. The script picks the build for your machine and puts it on your path.

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

If you would rather have a package manager own it, the same binary ships on npm and the package is a launcher around it.

npm install -g pilots

Sign in

pilot login opens a browser, signs you in with GitHub, and stores an API key for this machine. It is a command you run yourself: it holds a credential, so it is not one to hand to an agent or a script.

pilot login
pilot whoami

pilot whoami answers with the key, the fleet and the organization every other command will act as, and where each of those came from. It is the first thing to run when a command surprises you.

Run something in a sandbox

A sandbox is a machine. It has a shell, Node, Python and a permanent URL, it starts in well under a second because creating one is a restore rather than a boot, and it suspends by itself after 60s of quiet.

pilot machine create scratch
pilot machine exec scratch -- python3 -c "print(6 * 7)"
pilot console scratch

Creating one drops you into a console in it, and --skip-console is how a script says not to. exec runs one command and hands back stdout, stderr and the exit code. A console is a session that outlives its connection: detach from it and pilot attach comes back with what was printed while you were gone.

A suspended machine costs nothing and holds no memory on any host. The next request or exec wakes it with its processes exactly where they were, and a request that arrives while it sleeps is held rather than bounced, for up to 120s.

Put a directory on a URL

In the directory of an app, one call builds it and runs it as a service. The platform reads the directory to decide what it is: a compose file, then a Dockerfile, then a framework it recognises. Writing a Dockerfile first is the reflex to resist, because it is the step being removed.

cd ./my-app
pilot deploy
what it prints 
plan    web  webjs  (package.json, @webjsdev/core)
build   web  ok
deploy  web  healthy
web  https://web.pilotrun.app

The URL is permanent. It survives suspend, wake, redeploy, rollback, promotion to production and a move to another host, which is the one promise everything else here is arranged around.

When it does not work

  • Every error carries a code to branch on and a next naming the one thing to do. Read next and do that. The whole list is on the errors page.
  • unknown_framework means nothing recognised the directory. The answer carries the listing, the manifests and the two rules a Dockerfile must obey, which is enough to write one without opening the repository again.
  • health_gate_failed means the app never answered its health check. It is almost always the port or the bind address. Run pilot doctor on your own machine and diagnose on the replica before deploying again, because nothing changed and a second deploy will fail the same way.

Clean up, or do not

A sandbox you leave alone suspends and costs nothing, so there is no hurry. When you do want it gone, destroying it is irreversible and takes its checkpoints with it.

pilot status
pilot machine destroy scratch

Where to go next