Running a fleet

A fleet is just more devices: build boxes, GPU servers, cloud VMs, a NAS and the machines in a homelab rack, alongside the laptops people sit at. Each runs the alto service and keeps its own sessions; you reach all of them over Tailscale.

1. Make each machine a device

From your own machine, for anything ssh reaches:

alto add build-box           # or me@10.0.0.7, or a name from ~/.ssh/config

It finds the machine’s OS and architecture, sends it the matching alto, runs alto install there trusting your Tailscale login (so your devices reach it with no pairing), waits for it to answer, and lists it with what it says it is. Run it again and it says what’s already there. The machine needs Tailscale; without it, add says how to install it and changes nothing. Linux and macOS machines for now; Windows ones by alto install there.

add sends this machine’s own build to a machine of the same kind. For any other kind it needs that build in Alto’s builds folder, until published builds come.

On the machine itself, with nobody there, one command does the same:

alto install --trust "*@example.com"

It turns remote access on, trusts what --trust names, installs the login item (on Linux, running with nobody logged in) and says how to reach the machine. It’s safe to run again. Use it from cloud-init, an image or a container’s start script: see Services and containers.

2. Trust by tag, not by pairing

A six-digit code is right for a friend’s laptop and wrong for 300 servers. Let machines in by what Tailscale says they are:

alto devices trust tag:gpu          # every machine the tailnet's admins tag gpu
alto devices trust '*@example.com'  # everyone at your domain
alto devices trust                  # what's trusted now

Tags are given by the tailnet’s admins, so trusting one trusts their judgment. Tagged machines trusted this way are listed as yours, to open tabs on. With an ephemeral, pre-approved Tailscale auth key, a VM made for one job joins when it starts and leaves when it ends.

For a homelab, it’s simpler still: machines signed in to your own Tailscale account are already yours.

3. Put work where it fits

alto new --in 'os:linux gpu' -- claude          # whichever Linux machine with a GPU is least busy
alto new --in pool:win --repo -- claude         # on a Windows machine, in a checkout of this repository
alto --on gpu-1 new -- claude                   # or on the one you name
alto settings drain on                                      # on a machine: take no new work for now

Selectors, pools, max_sessions and sending your code are in Putting work where it fits.

4. See and reach all of it

alto ls --all                      # every session on every machine, as machine:id
alto ls --in 'status:needs-you'    # what's waiting on you, wherever
alto ls --all --group-by repo      # or by agent, os, kind, tag, pool, status, workspace
alto attach gpu-1:4                # watch it here
alto run build-2:3 -- make         # run a command there, get its output and status
alto devices                       # what each machine is, and how fast it answers
alto ls --count                    # how many are working, need you or are done, per machine

More in Every session, every machine. In the window, ⌘P jumps to any session on any machine, needing you first, ⌘⇧J to the next one needing you, and ⌘⇧L opens the fleet view, to look over and act on many at once; the menu beside + opens a tab on any device, in any profile, marked with the machine’s name in its own color.

5. Keep it current

Replace the alto file on a machine; its service notices within seconds and hands over to the new build, its sessions still running. alto reload does the same on purpose. See Updates and restarts.

For organizations Planned · Phase 9

Joining by tag, setup with nobody there, the queue across devices, placing work by what a machine is, pools, draining, listing and grouping every session, the switcher and the fleet view are built. Planned on top of them, for fleets of fifty to thousands:

• Machines that start when work needs them and go away after: containers first.
• Credentials handed to a session when it starts, and never left behind.
• Rules and a record. Who may read, type into, start or stop sessions in which group; sandboxes required per group; single sign-on; a log of who typed what, exported to your own tools.
• Rolling updates, a group at a time, with sessions moving to the new build in place.
• An optional hub for the overview, placement and rules, that nothing running depends on. If it’s down, every machine keeps running its own sessions and devices still reach each other.

What Alto won’t do: build environments from templates, or provide compute. Run it inside the workspaces, VMs, containers and sandboxes you already use, and each becomes a device.