Local vs AnvilHub — the two doors

Anvil is a tool that runs on your machine, with your provider keys, under your control. That is true whether or not you ever create an AnvilHub account. AnvilHub doesn't run Anvil for you and never holds your credentials or your code — it's a second door onto the Anvil you're already running: a web command centre that lets you see and steer it from anywhere, pull several machines into one fleet, and bring a team in.

Understanding this one idea — the host stays in charge, AnvilHub is a door onto it — explains almost everything else in these docs.

The three doors

Every Anvil deployment has a door setting (control_door) that decides how — and whether — it can be reached and managed from outside the terminal:

The door is runtime-switchable — you're never locked in. You pick one at setup, and you can change it later from the terminal (/local-control, anvil pair) or, once connected, from AnvilHub's Connection settings pane.

[!NOTE] A locally-built FIPS edition of Anvil ships with the hosted door compiled out entirely — it physically cannot phone home. The hosted door is an opt-in capability, not an always-present backchannel.

What the terminal already does on its own

Before talking about what AnvilHub adds, it's worth being clear about what you don't need it for. With the door set to None, Anvil is a complete coding and automation tool: ~148 commands, every provider and model, the full agent and squad system, memory, the knowledge base, the vault, routines, MCP and LSP — all of it runs locally. Nothing in the core product is gated behind an account.

The Local door adds a browser viewer for that same local Anvil — handy on a desktop, or to reach a workstation from a laptop on the same network — without any cloud in the path.

What connecting to AnvilHub adds

AnvilHub earns its place when one terminal on one machine stops being enough. Each item below is something the hosted door makes possible that a bare terminal cannot do — not a nicer version of a local feature, but a genuinely new capability:

• A fleet. One machine only knows another machine exists because AnvilHub carries messages between them. Connect two or more deployments and you can see them all, and hand a task to whichever one should run it, from a single screen.
• Crew output you can actually see. The terminal shows an agent's work as it scrolls past. AnvilHub keeps it — every run, its changeset, its artifacts, its cost — on the Runs and Canvas pages, long after the session is gone.
• Cost rolled up across everything. Not one session's spend — every bot, every day, every routine, every person, across every connected machine, with honest handling of anything the provider didn't price.
• A team. Invite people, give them roles, set seat limits, hand over ownership. There is no terminal equivalent; orgs live on the web.
• Approvals that outlive the session. When an agent asks to do something it isn't yet allowed to, that request becomes a durable item an admin can decide later — even after the original session has ended — instead of a prompt that dies when you close the terminal.
• Steering from away from the keyboard. Change a machine's config, add a provider key, create or pause a bot, edit a routine — from the web, and the change applies on the host the next time it checks in, even if it was offline when you made it.

The through-line: the host stays authoritative. AnvilHub observes it, queues instructions for it, and relays traffic to it — it never holds your keys, your documents, or your memory. A web edit isn't applied by AnvilHub; it's filed as a command the daemon picks up and applies itself.

How to connect — pairing

Connecting a machine to AnvilHub is called pairing (or claiming). It is deliberately something that starts on the machine, with a one-time PIN, so that nobody can bind your deployment to their account just by knowing it exists.

[!WARNING] Pairing is anvil pair, not anvil login. anvil login connects a provider (your Anthropic/OpenAI/Ollama credentials). anvil pair connects this deployment to your AnvilHub account. They're unrelated.

The flow:

1. On the machine, run:

   anvil pair
   

   Anvil contacts AnvilHub, prints a claim URL and a 6-digit PIN, and (if it can) opens the URL in your browser.
2. In the browser, signed in to AnvilHub, open that claim URL. You'll be asked to name the deployment (e.g. "workstation", "build-box") and to type the PIN the terminal printed.
3. Anvil, still waiting at the terminal, sees the pairing confirmed, saves its binding, and flips its door to AnvilHub. Done — the machine now appears on your Instances page.

Check status any time with anvil pair status (it never prints the secret token). To connect a headless server with no browser, the pairing is the same — open the printed claim URL from any browser where you're signed in.

On AnvilHub, the Instances page is where machines live. Note that it shows pairing instructions, not a form — because nothing a browser does can bind a daemon; pairing always begins on the machine with anvil pair.

Once paired — what the host reports

A paired daemon checks in with AnvilHub on each session and reports a picture of itself: who it is, what agents and capabilities it has, which bots it's running, which clients are attached. In return it picks up anything you've queued from the web — a config change, a capability to install, a task for the fleet. That exchange is the whole control plane. Unpaired, none of it exists, and Anvil is simply a local tool.

Where to next

• Setup & first run — where you first choose a door.
• Doing it in AnvilHub — the command-for-screen map: how each terminal action looks on the web.
• Instances & the fleet — managing many machines as one.
• Security & the vault — why the host never hands its secrets to the hub.