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 server and keeps its own sessions; you reach all of them over Tailscale.

1. Make each machine a device

On a server, with nobody there, one command does it:

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

It turns remote access on, trusts what --trust names, installs the login service (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 Servers 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. Work across all of them

alto --on gpu-1 new -- claude      # start an agent there
alto --on gpu-1 ls                 # what's running there
alto --on gpu-1 attach 4           # watch it here
alto --on build-2 run 3 -- make    # run a command there, get its output and status
alto waiting                       # every agent waiting on a person, on every device, newest first

In the window, the menu beside + opens a tab on any device, in any profile, marked with the machine’s name in its own color.

4. Keep it current

Replace the alto file on a machine; its server 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 and the queue across devices are built. Planned on top of them, for fleets of fifty to thousands:

• Groups, not rows. Devices grouped by tag (“gpu”, “linux-build”), each showing counts of working, waiting and done, and the needs-you queue sent to the right person, phone included.
• Say what, not where. Start an agent’s profile in a group and Alto picks the machine by tags and load. Drain a machine so no new sessions go to it.
• Rules and a record. Who may read, type into, start or stop sessions in which group; sandboxes required per group; secrets handed to a session when it starts; 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.