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 open

This checks that the daemon is up and opens the console in your default browser, signed in. The console also opens automatically at the end of an interactive bootstrap. Two sibling verbs cover scripting and lockouts:

burrowee gateway console-url            # print the signed-in URL without opening a browser
burrowee gateway console-rotate-token   # mint a new token — signs out every session (root)

The console binds loopback only — 127.0.0.1 — and is never reachable from the network. Access on the machine is gated by a bearer token stored under the gateway's config root (console.token, readable by the machine's admin group): the signed-in URL carries it, so only an admin-group user can produce a working URL, and rotating it requires root. That local-admin authority is also why the console 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's main tabs are Targets, Clients, Relays, and Services, plus Live, Daily, and Logs stats tabs that mirror the cloud console's stats views — live bandwidth with a per-relay rollup and carrier drill-down, daily byte counters, and a connection log. Open sessions are visible in the live view while they are open, with the carrier each one rides named on its row.

Targets

The default tab — everything this gateway exposes, split into Web and Raw sections, one row per target with its name, local address, protocol (shown as a single http(s) badge, or raw), 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. Rows carry a universal copy button, a quick 🌐 public/private toggle per domain, and a ≡ action menu (Activate/Deactivate, Delete with inline confirm; custom/random domain actions hand off to the cloud console). Domain liveness is checked in two tiers, and only a live domain's URL is copyable.

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, re-pointing its address, or changing its Protocol in place all 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" 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, though it isn't rendered as its own column yet.)
• 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 — system relays first, then by address: the System relay (your shared fleet assignment) and your Edge relays, each with connection state, carrier state, LAN origins, certificate-pin status, and whether the co-located local path is currently in effect. 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: Service & restart → Updates.

Console password (remote access)

The local console can be exposed through a relay as a target of its own (see Targets → Exposing the local console itself). That remote console is guarded by a password you set with:

burrowee gateway console password

Interactive and no-echo by default, with a confirm prompt; changing an existing password always requires the current one, and there is no recovery or reset path — a forgotten password means setting a new one from the gateway machine. For provisioning scripts there's --stdin; passing the new password as an argument works only for the initial set (and warns, since argv lands in shell history).

The password must be 4 to 32 characters, enforced by the gateway itself so the CLI and the web form can't disagree. A short, PIN-style password is survivable because the remote gate admits password attempts one at a time, spacing them further apart after every consecutive wrong guess (roughly 2,880 attempts a day at its slowest, for the whole gateway), and every spent wrong guess is audited. Under a sustained attack the remote console may become slow or unavailable by design — the local loopback console never passes through this gate and stays available on the machine; its URL is named in every refusal.

Behind the UI

The console's UI is a thin client over a loopback JSON API behind the web UI, gated by the same bearer token. The burrowee gateway target … and burrowee gateway relays … commands drive the gateway through the same machinery, so anything you do in the UI has a command-line equivalent.

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.