Instances & the fleet

Each machine running Anvil is an instance — a workstation, a build box, a server. On its own, an instance knows nothing about any other; the terminal is a view onto that one machine. Pair two or more to AnvilHub and they become a fleet: a set of machines you can see together and direct from a single place.

Why a fleet needs AnvilHub

This is worth being precise about, because it's the clearest example of what the hosted door uniquely enables. Anvil's local relay connects a machine to a viewer — a browser looking at that machine. It does not connect one machine to another. The only thing that carries a message from one instance to another is AnvilHub.

So a bare terminal can plan fleet work — it just has nowhere to send it. Connect the machines to AnvilHub and that plan has a path: hand a task to whichever instance should run it, and AnvilHub routes it there.

The Instances page

On AnvilHub, Instances is the home for your machines. For each one you can see its status and which instance your current workspace is pointed at, and you can:

• Rename it to something you'll recognise.
• Set its lead agent.
• Revoke or remove it when a machine is retired.

Adding a machine is pairing, and the Instances page shows the instructions for it rather than a form — because, as everywhere in Anvil, binding a daemon has to begin on the machine with anvil pair, never from the browser.

Handing work to the fleet

Once you have more than one instance, you can dispatch a task to a specific machine from AnvilHub — the right one for the job, whether that's "the box with the GPU" or "the server that can reach the database." AnvilHub fetches the current fleet, you choose where the work runs, and it's routed to that instance's host to execute. The result comes back to the web surfaces — Runs, Canvas — like any other work.

In the terminal, /fleet is the counterpart: it can reason about the fleet and build a plan, with AnvilHub as the transport that actually delivers it.

What each instance reports

A paired instance keeps AnvilHub's picture of it current — its identity, the agents and capabilities it has, the bots on its team, the clients attached to it. That's what makes the fleet view accurate: you're not looking at a cache you have to refresh by hand, you're looking at what each machine last told the hub about itself.

Where to next

• Local vs AnvilHub — the doors, and how pairing works.
• Bots & the Team board — the crew on each instance.
• Runs — every run across the whole fleet, with cost.