Local console

Every running gateway serves its own management UI on the gateway machine: the local console at http://127.0.0.1:16518. Open it any time with:

burrowee gateway console

This checks that the daemon is up, prints the URL, and opens it in your default browser. If the daemon isn't running, it prints the URL anyway along with a hint to start it (burrowee gateway restart). The console also opens automatically at the end of an interactive bootstrap.

The console binds loopback only — 127.0.0.1 — and is never reachable from the network. Being on the machine is the access control, which is also why it can show you secrets (like page-share seeds) that the cloud console never displays. On a headless host you can disable it entirely by running the daemon with --console off.

A tour of the console

Header — name and identity. The top bar shows the gateway's display name (click it to rename — the new name syncs up to the cloud console) and the gateway's key fingerprint, the short hex string that identifies this gateway's public key everywhere else in Burrowee.

Status strip. A one-row dashboard across the top: gateway connection state, how many relays are connected, the share host, uptime, and live target and session counts. The Auto-refresh and Refresh buttons on the tab bar control how eagerly the whole page polls.

Targets. The main tab — the list of everything this gateway exposes, one row per target with its name, local address, protocol (handler type), attached domains, TLS state, and session count. + Add target creates one; expanding a row gives you the per-target detail, including its sessions and domains.

Sessions. Sessions live inside each target's detail view in the Targets tab. From there you mint full sessions and page-share keys, copy their links, relabel them, set or extend their expiry (the expiration dialog takes 1–365 days), share them, and revoke them. The full session model is covered in Sessions.

Domains. Also part of the target detail: each web target shows the domains attached to it — random-pool *.burrowee.net names and custom domains — with a Manage domains → link out to the cloud console, which owns DNS and certificates. A counter shows your remaining random-domain allowance.

Relays. Lists the relays this gateway dials, split into the System relay (the shared fleet assignment) and your Edge relays, each with its connection state, LAN origins, and certificate-pin status. The Add an edge relay box at the top accepts a setup blob + PIN minted in the cloud console (console → Edge relays → Add to gateway) — pasting it here is equivalent to running burrowee gateway relays pair <blob> <pin>, and a picker lets you choose which LAN origins to enable.

Clients. The machines paired to this gateway with the Burrowee CLI. The Paired subtab lists them by label and public key and lets you unpair any of them; Pending holds incoming pairing requests waiting for your decision.

Pairings. Letting a new CLI client in is a deliberate two-step, and both halves live in the Clients tab. Pair a client → Generate pairing mints a one-time blob + PIN to hand to the client's owner (they run burrowee cli bootstrap <blob> <pin>); when their request arrives back through the relay it appears under Pending, where you Approve or deny it. Nothing connects until you approve.

Settings. The gateway deliberately has few knobs — its configuration is the bootstrap blob plus what you see in these tabs. The settable things live where they apply: the gateway name in the header, relay membership in the Relays tab, per-target options in each target row. Daemon-level switches (--home, --console off, --no-open) are command-line flags on the service, covered in Service & restart.

Local vs cloud console

The cloud console at console.burrowee.com shows the same gateway — its targets, sessions, and domains — and lets you manage it from anywhere. But the relationship is one-way: the gateway is authoritative. The cloud console mirrors the gateway's state (the gateway syncs it up through the relay) and remote-controls it (a dashboard action travels down to the gateway, updates the gateway's local store, and syncs back). The local console talks to that store directly, so it works even when the cloud is unreachable — and a few operations, like revealing a page-share seed, are local-console-only by design.