Gateways

Gateways is the heart of the console: one row per gateway, with a detail page per gateway where you manage its targets, domains, relays, and sessions remotely.

The list has two tabs. Personal shows gateways enrolled under your own account; Team shows the gateways of the teams you belong to (a gateway lives on one team at a time — see Moving a gateway into a team). Each row shows the gateway's name, an online dot, when it last synced, and its target and session counts. Three buttons above the list — + Add gateway, Install gateway, and Install CLI — cover onboarding a new machine; the latter two just open the one-line installers without the setup wizard below.

Creating a gateway

Click + Add gateway. The dialog walks you through the two halves:

1. Install the gateway on the target machine — the one-line installer, also covered in Install.
2. Generate setup. Enter a hostname (for example home — it labels the gateway and must be unique within your account) and click Generate setup. The console assigns your relay set and returns a one-time setup blob and PIN, plus the full command that combines them:

burrowee gateway bootstrap <blob> <pin>

Run that on the gateway machine, or paste the blob and PIN into the gateway's local console under Relays → Pair a relay. The PIN is shown once.

The blob is safe to send over any channel — it is useless without the PIN. Until the gateway completes its bootstrap, the row shows a Setup pending badge; clicking it opens Complete setup, which regenerates a fresh blob and PIN on the spot. Generate as many as you need; only the latest counts.

3. Approve the gateway. A newly bootstrapped gateway starts awaiting approval — its row shows an Awaiting approval chip, and the relays refuse to serve it until you confirm the enrolment you expected. Open its detail page and click Approve gateway on the banner; the relays start serving it within about 30 seconds. (Gateways enrolled before this gate existed are treated as approved.)

Your plan caps how many active gateways you can have. At the cap, the + Add gateway button is replaced by a "Gateway limit reached" note.

The gateway detail page

Click a gateway's name to open its detail page.

Header. The gateway's display name (click it to rename — up to 64 characters; renames sync down to the gateway, and a rename made in the local console syncs up here), its key fingerprint, a live/offline indicator, and when it last synced. Chips on the right show target, session, and relay counts, plus a Pairing button.

The Pairing modal. The Pairing button opens a modal with two tabs:

• Re-pair gateway (the default) mints fresh one-time bootstrap material — blob + PIN — for this gateway. Run burrowee gateway bootstrap <blob> <pin> on the gateway machine again and it re-enrols in place, without dropping out of service. Use it when the gateway's pairing material was lost or needs rotating. A re-paired gateway goes back to awaiting approval — approve it again before the relays serve it.
• Pair CLI doesn't mint anything itself — it's a guide pointing you at the gateway's own machine. For security, the secret that lets a burrowee cli client reach this gateway is generated and approved entirely on the gateway's local console, never through the cloud: open the local console, go to Clients → Pair a client → Generate pairing for the one-time blob + PIN, then approve the incoming request under its Pending subtab. Full walkthrough: Pairing → a different thing: pairing a CLI client.

Relays panel. Click the relays chip to expand the full set of relays carrying this gateway — kind (system or edge), host, and whether each is reachable. To put one of your own edge relays on this list, use Pairing on the relay's row on the Edge relays page and paste the resulting blob into the gateway's local console.

Alias domains. A panel to attach one of your custom domains to the gateway itself rather than to a single target — add a hostname, verify it via DNS (the panel shows the relay addresses to point the DNS record at), or remove one. A gateway alias is a distinct kind of custom domain, separate from the per-target attachments in the targets table below.

Update. One button pushes a version update to the gateway through its relay, in two phases: the standalone updater is brought up to date first, then the gateway component itself — the button relabels for whichever phase is running, with live apply progress. A separate Update updater control sits beside it for updating just the updater. A push that can't run tells you why (the refusal reason is shown — for example the node's updater daemon isn't ready, or the gateway's own cloud-push setting refuses it) rather than failing silently. The version panel shows the running version only, with an "Up to date" note on the Current-version line when there is nothing to push.

Stats. A tabbed Live / Daily view of the gateway's traffic. Live refreshes every 10 seconds: current bandwidth, live sessions with per-carrier session counts, and a per-relay drill-down. Daily offers a calendar of daily figures with a per-day connection log. Every tab, drill-down, and log day is a real URL — bookmark it or share it and it opens on the same view. Byte figures throughout use binary IEC units (GiB, MiB, KiB).

The targets table

The Targets section is the main surface: one row per target the gateway exposes, with columns for name, local address, protocol, domains, TLS, sessions, and actions. Targets are split into two sections — Web targets and Raw targets — each row carrying its protocol label. A filter strip scopes the table to targets with Custom domains, Random domains, or Domainless ones, with counts per bucket; a meter shows your random-domain quota (used / limit). A target's notes fold into a single icon on its row — hover or click it to read them.

Raw (TCP) targets work differently from web ones. A raw target is reached at <service>.<relay-domain> — the service name as a subdomain of each relay's own domain — and its row carries a distinct connection block listing those relay addresses. Raw targets never get a random domain (the random-domain controls are hidden; attaching a custom domain still works), and they have no sessions — access control lives elsewhere.

Per row you can:

• Rename the target — click its name and type. Renaming carries the target's sessions and domains with it.
• Edit the upstream address in place — click the local address and type, just like a rename.
• Change the protocol in place — click the protocol badge and pick http(s) or raw. Always change it in place; deleting and recreating a target kills its sessions.
• Deactivate / Activate — pause a target without losing its configuration. If the gateway is offline the change is saved and shows a pending apply badge until the gateway reconnects.
• Share with team / make private — on a team gateway, an owner can toggle a target's visibility. A shared target is visible to every team member with access to the gateway; private keeps it visible to the owner only. Non-owners see the badge read-only.
• Delete — a double-confirm dialog that spells out the cost: the target is removed, all its sessions are revoked, and any random domain it held is released. You must tick "I understand" first.

Domains, per target

The Domains cell lists what is attached to the target — custom domains first, then its random *.burrowee.net name:

• Claim a random domain (quota-gated) or attach a custom domain via Assign domain. Attaching a custom domain that currently lives on another target moves it here — the certificate carries over, so TLS is uninterrupted.
• + Add domain opens the custom-domain dialog pre-scoped to this target.
• The lock icon shows TLS readiness; the ⓘ icon opens a per-domain relay picker — Auto serves the domain on every relay the gateway connects through, or pin it to one of your edge relays. (Random domains are wildcard-issued and always serve on all relays.)
• The globe icon toggles the domain public. A public domain serves with no session token — anyone who can reach the hostname reaches the service — so making one public asks you to confirm. Toggling back to private is immediate.
• The ✕ detaches a custom domain or releases a random one (confirm required).

A target on the shared relay fleet with no domain at all shows a disconnected badge — it is not reachable in a browser until you assign one (or, if your quota is spent, take over a random domain from another target).

Sessions, per target

Each target row's N sessions button expands its own session list, with an inline create row to mint new ones. The full session model — minting, TTLs, sharing, page-shares — is on the Sessions page. When the gateway is offline, the sessions view is unavailable: sessions are live gateway state, and the mirror would be stale. Raw targets have no sessions, so the control doesn't appear on them, nor on targets whose domains are all public (no token is needed to reach those). On a team gateway, the team's owner and managers hold full session authority on shared targets — create, share, extend, revoke — alongside the target's creator; members can't manage sessions but do receive the credentials (the Copy affordance) so a shared session is actually usable. See Sessions → Sessions on a team.

Moving a gateway into a team

Each row on the Personal tab has a Move to team button — pick one of your teams (it must be active) and the gateway moves there, appearing on every member's Team tab under their own role. It's a one-way move, not a share: the gateway leaves your Personal list, and billing follows the team from then on. A gateway with custom domains or edge routes attached must have those removed first.

On the Team tab, the gateway's owner gets a matching Move to personal button to bring it back — team members lose access immediately.