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.

Turning it off, and changing its port

On a headless host, or if you'd rather manage everything from the cloud console, disable the local console entirely by serving with --console off:

burrowee-gateway --console off

(the managed service always passes --no-open, never --console off — to disable it under a service, edit the service's invocation or use the config key below and restart). The port itself is configurable — see console_port in Service & restart → Configuration; the host is always 127.0.0.1 and can't be changed.

A tour of the console

Header. 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. Auto-refresh (on by default, persisted per browser) and Refresh on the tab bar control how eagerly the whole page polls.

The console has four tabs: Targets, Clients, Relays, and Services.

Targets

The default 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 opens an inline form (name, host:port, handler type); click a row to expand its detail.

Each target row's detail panel is also where you manage that target's sessions — mint full sessions and page-share keys, copy links, relabel, extend or set expiry (1–365 days), share, and revoke or delete. The full session model is covered in Sessions; the page-share seed-reveal modal here is loopback-console-only, for the reason above. Domains for a web target — the random-pool *.burrowee.net name and any custom domain — also show in the target's detail, with a Manage domains → link out to the cloud console (which owns DNS and certificates) and a counter for your remaining random-domain allowance.

Renaming a target, or changing its Protocol in place, both apply live; see the warning about deleting vs. renaming in Targets. Deleting a target (and removing a client, elsewhere in the console) uses a two-step confirm: the button relabels itself "Confirm delete/remove" for ~3 seconds before it will actually act, so a stray click never destroys something by accident.

Clients

The machines paired to this gateway with the Burrowee CLI, split into two subtabs:

• Paired — lists each client by label, key fingerprint, when it paired, and when it was last seen, with a two-step-confirm Remove to unpair it. (The gateway also records each client's last-reported CLI version; it isn't rendered as its own column yet, but is available from the underlying JSON API.)
• Pending — incoming pairing requests waiting on you.

Pair a client → Generate pairing mints a one-time blob + PIN for you to hand to the new 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 (also two-step-confirmed). Nothing connects until you approve. This is entirely local — see Pairing → a CLI client for why the cloud console can't do this for you.

Relays

Lists the relays this gateway dials: the System relay (your shared fleet assignment) and your Edge relays, each with connection state, LAN origins, and certificate-pin status. The Pair a relay box at the top accepts a setup blob + PIN minted in the cloud console (console → Edge relays → row [≡] menu → Pairing) — pasting it here is equivalent to burrowee gateway relays pair <blob> <pin>, and a picker lets you choose which LAN origins to enable. Each edge relay row also has the same local machine toggle as burrowee gateway relays local <id|host:port> on|off (see Pairing) — flip it if the relay runs on this same box, so the gateway prefers dialing it over loopback.

Services

A per-process status table for the three things the gateway install bundle runs: the gateway daemon, the console (this UI, a child of the daemon), and the updater. Each row shows running/stopped, PID, version, and uptime, and gets an update available badge once a newer release exists.

Two buttons act on it: Update gateway/console and Update updater — both disabled until their respective row shows an update available. This local, in-console update is always available regardless of allow_push_update (that config key only gates the cloud console's push button — see Service & restart → Configuration); local authority on the machine itself is never gated. Full command-line equivalent and the versions block in status/doctor: Service & restart → Updates.

JSON API

The console's UI is a thin client over a plain JSON API served on the same loopback port (no auth — being on the machine is the access control), so any local script can drive everything the UI does with curl. The burrowee gateway target … and burrowee gateway relays … commands use the same API under the hood. Endpoints are easy to discover from your browser's network tab while using the UI.

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 or pairing a CLI client, are local-console-only by design.