Skip to content
pilots
Dashboard GitHub (opens in a new tab)

One file on your PATH

The CLI and the terminal dashboard are the same static binary. It has no runtime under it and no daemon beside it, so installing it is downloading a file and removing it is deleting one.

Read the script Every release (opens in a new tab)

Two ways in, the same binary

any Linux or macOS shell 
$ curl -fsSL https://pilots.run/install.sh | shpilot: looking for pilot_linux_amd64pilot: sha256 verifiedlands in ~/.local/bin, and asks for no sudo

The script is short enough to read before you run it, and the same address in a browser shows it as text. It picks the binary for your system from the latest release, checks it against the checksum file published beside it, and renames it into place, so a download that dies halfway never leaves a broken command behind.

with Node already installed 
$ npm install -g pilots$ npx pilots deploythe second line runs it with nothing installed

The package carries the binary for every supported system and a launcher that picks yours. No install script downloads anything, so it works with scripts disabled and behind a registry mirror. The command it installs is pilot.

From installed to a URL

Four commands cover most of what people do in the first session, and pilot --help groups the rest by what you are trying to get done.

  1. pilot login

    Opens the GitHub device page in a browser and stores a key in ~/.config/pilots/credentials, a file only your user can read. On a machine with no browser, --token stores a key you already have.

  2. pilot deploy

    Run it inside a project. It takes a compose file, a Dockerfile, or neither, and a WebJs app needs no configuration at all. The last line it prints is the URL.

  3. pilot mcp install claude-code

    Writes the fleet into your coding agent's config, merged with what is already there. The agents page lists every harness it knows.

  4. pilot tui

    The fleet as a terminal dashboard you leave open: machines, services, logs and a console, from the same binary.

Upgrading follows how it arrived

Installed by the script

pilot upgrade

Downloads the newest release, checks it against the checksum file published beside it, and swaps it in with one rename, so an interrupted upgrade leaves the old binary working. pilot upgrade --check reports and changes nothing.

Installed from npm

npm install -g pilots@latest

That file belongs to npm. pilot upgrade notices where it is running from and prints this command, and leaves the file alone.

Removing it

rm ~/.local/bin/pilot

Or npm rm -g pilots. Your key is the one other file, ~/.config/pilots/credentials. Delete both and nothing of the CLI is left on the machine.

Where it stops

Two limits worth knowing before you depend on it.

Linux and macOS, x64 and arm64

There is no Windows binary, because the CLI does not build for Windows. WSL is Linux, so both commands above work there unchanged. On Windows itself the npm launcher says exactly this and points at WSL, so the failure explains itself.

A checksum is not a signature

The checksum proves the file you received is the file the release published. Someone able to replace a release could replace its checksum file as well. The npm package carries a provenance record, which ties it to the commit and the workflow run that built it, and the source (opens in a new tab) builds with go build ./cmd/pilot from apps/pilot.