Skip to content

pilot v0.3.0

Choose a tag to compare

View all tags
@vivek7405 vivek7405 released this 23 Sep 05:23
pilot-v0.3.0
eaf650a

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.

Assets 7
Loading