pilot v0.4.0

This release is about not being sent to a web page. Setting up push-to-deploy, running a team, minting a token and changing a plan could only be done in the dashboard, so an agent holding the CLI could get you a URL and then had to stop and tell you to go and click something. All of it works from the terminal now, and from the MCP toolset an agent drives. Upgrade with pilot upgrade, or npm install -g pilots@latest.

Added

• pilot repo deploy acme/shop takes a repository to a URL with nothing checked out. It claims the repository for your team, opens the GitHub App install page and waits if the App is not on that account yet, creates the service, builds, releases, and wires push-to-deploy. One command, and the only thing you do is approve the GitHub screen.

  Connecting a repository could not be done from a terminal at all before this, by anyone without an admin key. The claim needed a service, creating a service from a repository needed a build, and a build needed the claim — a circle a normal key could not enter at any point.

• pilot repo connect | disconnect | show | ls. connect writes both halves of push-to-deploy: your team's claim on the repository, and the service's branch. When the App is missing it opens the install page and waits, rather than printing a URL and asking you to run the command again — which was silent when you forgot, because the service looked wired up and no push ever arrived. ls shows the repositories you granted, so you pick one instead of remembering its exact name.

• pilot org create | rename | delete | members | invite | remove | transfer | leave. Running a team from the terminal. Inviting a teammate carries no secret and needs no consent screen, and it needed a browser.

• pilot key create | list | revoke, with --org to mint for a team you belong to. admin scope is still owner-only and still refused to anyone else, exactly as the consent screen refuses it.

• pilot billing show | activate. A plan here is a set of limits the fleet holds your team to. When a payment provider is configured, activate opens its page and waits for the plan to actually move, rather than reporting success at a checkout you have not finished.

• A repos tab in pilot tui, beside machines and services: which service deploys from which repository, and on which branch. It reads the same fleet snapshot the other two do, so the dashboard being unreachable cannot blank it — pilot tui talks to the fleet and nothing else.

• Colour. States are green, amber or red the way the dashboard paints them, error: is red, and the next step is in the colour used for anything you are meant to type. It turns itself off when the output is not a terminal, under --json, under NO_COLOR and on a dumb terminal, so pilot machine ls | awk '{print $1}' is unchanged.

• 22 new MCP tools for agents: repos, repo_claim, repo_connect, repo_disconnect, repo_deploy, teams, team_admin, keys, key_revoke, billing, billing_activate, service_set, domain_add, domain_remove, builders and more. An agent can now change a service, attach a domain and reset a builder, where before it could only read them.

  There is deliberately no tool that mints a token or sets a secret: the value would travel back through the conversation. Those stay commands you run.

Changed

• pilot builder reset names a builder, not a host. It took a host id, which made you go and find the one identifier this product promises nothing about — a machine may be on a different host tomorrow. It now takes a builder id from pilot builder ls and finds the host itself. If you have this in a script, the argument changes.
• pilot machine ls and pilot service ls show CREATED instead of ID. Every command takes a name and resolves it, so the id was a column nobody typed and everybody scrolled past; "3d ago" is the question you actually have in front of a list. Both fields are unchanged under --json, which is what a script reads.

Upgrading from 0.2.0 or 0.3.0, which pilot upgrade cannot do for you

If you are on 0.2.0 or 0.3.0, pilot upgrade will tell you no release has been published. It is wrong, and re-running it will not help. Those binaries ask GitHub about the repository the source used to live in, and that repository is now private, so GitHub answers "not found" and the CLI reports it as nothing having been published.

Install this one the way you first installed it, and pilot upgrade works from here on:

curl -fsSL https://pilots.run/install.sh | sh
# or
npm install -g pilots@latest

Fixed

• pilot upgrade will not move you backwards. It compared the published version against yours for difference, not order, so a binary ahead of the latest release — a prerelease, or one you built — was replaced by an older one and told upgraded pilot v0.4.0 -> v0.3.0. It now installs only what is newer, and --force is the way to go back on purpose.
• pilot claude no longer asks for a browser login every time it starts. #185
• Installing and upgrading works without an account. The install script and pilot upgrade fetch from a public location again, so neither needs credentials. #193
• The npm page no longer promises provenance it does not carry. #195
• A CLI newer than its fleet's dashboard says so. A team or token command against an older dashboard answered "the dashboard answered 404 / try again", which sent people to report a version difference as a bug and to retry the one thing that cannot start working. It now names the dashboard as older than your pilot.

Known limits

• Repositories owned by a GitHub organisation are not listed by pilot repo ls. They connect by name, and everything else about them works.
• The team, token, plan and repository commands need the fleet's dashboard to be current. They are the one part of the CLI that talks to it rather than to a host; pilot deploy and everything else keep working when it is down.

---

Install, or upgrade an install the script made:

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

From npm: npm install -g pilots@latest. Every way in is on https://pilots.run/install.

pilot v0.3.0

This release makes signing in work. On 0.2.0 a pilot installed from the script or from npm could not authenticate at all, and pointed at a fleet on your own laptop: anyone who did not build the binary themselves was stopped at the first command. Upgrade with pilot upgrade, or npm install -g pilots@latest.

Fixed

• pilot login works on an installed binary. It asked GitHub for a device code only when PILOT_GITHUB_CLIENT_ID was set in the environment, and nothing set it, so a user who installed the release was asked for an API key they had no way to obtain. The client id is now built in, and it is still overridable for a fleet that runs its own GitHub App.

  Login opens a browser where there is one to open. An SSH session, a CI job, or a machine with no display server prints the URL instead, because a browser that silently fails to appear is worse than the address you can copy.

• A fresh install talks to the public fleet. The built-in default was http://api.pilots.localhost:8080, which is right for a single-box runbook and wrong for every installed copy: pilot login filed a key against an address with nothing behind it, and the first pilot deploy dialled a port on the user's own laptop. Every override still applies in the order it always had.

• A failed deploy says what went wrong. The fleet has always carried the cause of a 500 in details.cause and every client dropped it, so a deploy that failed printed the category rather than the reason. It now prints the cause, which is usually one sentence naming the thing that did not answer.

• A deploy recovers a cold image instead of failing. The first rollout of a brand-new image can time out waiting for the guest agent, and rebuilding produces a different image that is cold again. pilot deploy now deploys the same build a second time, which is warm, rather than leaving you to do it by hand.

• pilot machine logs --tail exists. The agent skill's own table has answered "the end of a log, not the boot" with that flag for months while the command had only --follow. It does nothing under --follow, which starts from the end regardless, and the help says so.

• Commands that were printed but never existed. machine show, service update, service url-auth, machine promote, machine restart, service rm, volume snapshots restore, tokens and env set were all named in help text, error hints or the agent skill, and each answered "unknown command" to anyone who followed the advice. So did pilot domain add --service web --hostname app.example.com, which takes two positional arguments, and pilot machine create --name scratch, where the name is positional. Every one of them now names a command you can run.

• pilot mcp install prints the file it wrote the way you would type it, ~/.claude.json rather than an absolute path, and the verify hint it ends on is the one the harness table carries.

Added

• Command groups are singular. pilot machine create, pilot service deploy, pilot volume ls, and the same for domain, secret, org, builder, process and session. Every plural is kept as an alias, so pilot machines ls and pilot svc deploy work exactly as before and nothing you have typed or scripted breaks. Only what the CLI says changed.

• Checkpoints in the TUI. A machine's checkpoints are a screen of their own, and restoring one is a keystroke from there rather than a command you have to leave the dashboard to type.

• Suspend and wake from the TUI's lists, on either tab. s and w used to reach a machine only through its detail screen, and did nothing at all on the services tab. On a service they now act on every replica at once rather than one after another, because a suspend uploads a memory image and eight in sequence is most of a minute of screen that looks dead. A partial failure says how many landed.

  A service held above zero by min_machines_running refuses instead of pretending: the autoscaler would wake it within a tick, which reads as a bug in the screen rather than as the floor doing its job.

• A sign-in screen that asks one thing. The consent screen put a name prefix, a machine cap and an expiry in front of anyone running pilot login. They are the right questions for an agent that registered itself and noise for a person opening their own terminal, so they moved into a disclosure for whoever wants a scratch key with a cap.

Changed

• The fleet's hosts are out of the CLI. No command names a host or says which one a machine landed on. No request path depends on a particular host and a machine may wake on a different one tomorrow, so a CLI that showed you one was teaching you to depend on the single thing the architecture does not promise.

Limits

• There is still no way to delete a service. db ha disable used to tell you to run pilot service rm, which has never existed and has no route behind it; the note now says so and points at destroying the machines as what stops it costing anything.
• Linux and macOS only, on both common processor families. WSL is Linux, so the install commands work there unchanged. What we operate has the rest.

---

Install, or upgrade an install the script made:

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

From npm: npm install -g pilots@latest. Every way in is on https://pilots.run/install.

pilot v0.2.0

The first published release of pilot, the command line and terminal dashboard for Pilots, as one static Go binary. It succeeds the TypeScript CLI's 0.1 line, which was published as @pilots/cli and is now deprecated.

Added

• Two ways to install. curl -fsSL https://pilots.run/install.sh | sh puts the binary in ~/.local/bin with no sudo. npm install -g pilots carries the binary for every supported system and runs no install script, and npx pilots deploy runs it with nothing installed. Both are on the install page.

• The installer verifies, or installs nothing. The download is checked against the checksums.txt published beside it. A checksum that cannot be fetched, a missing line, a mismatch, or a machine with no sha256sum or shasum each stop the install before anything lands on your PATH.

• pilot upgrade verifies too. The new binary is checked against the same file before it replaces the running one with a single rename, so an interrupted or tampered download leaves the old binary working. pilot upgrade --check only reports.

  A binary that npm or Homebrew installed is left to its manager: pilot upgrade and --check both print the command that upgrades it there.

• One command line for sandboxes and services. pilot deploy takes a directory to a URL from a compose file, a Dockerfile, or neither. pilot machines, console, exec, file and proxy drive a sandbox, pilot promote turns one into a service without changing its URL, and services, logs, domains, secrets and volumes run it in production.

• pilot tui. The fleet as a dashboard you leave open, from the same binary.

• pilot mcp install <harness> connects Claude Code, Codex, Cursor and the other agents listed on the agents page to the fleet's hosted MCP server.

Limits

• Linux and macOS, on x64 and arm64. There is no Windows build. WSL is Linux, so both installs work there unchanged, and on Windows itself the npm package says so and points at WSL.
• A checksum proves the file you received is the file the release published. It is not a signature. The npm package carries a provenance record that ties it to the commit and the workflow run that built it.

---

Install, or upgrade an install the script made:

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

From npm: npm install -g pilots@latest. Every way in is on https://pilots.run/install.