Edge relays

The Edge relays page manages the relays you run yourself — on a VPS to serve your own domain, or on a LAN box for fast local paths. What an edge relay is for, and how to install and operate one, is the Edge guide; this page covers the console side: registering, approving, wiring to gateways, sharing, and retiring.

Edge relays require the Pro or Team plan. The list has Personal and Team tabs (mirroring Gateways) — Team shows edges owned by a team, or personal edges you've shared into one. Filters above the table narrow it by gateway (including an Unpaired filter for edges no gateway uses yet) and, on the Team tab, by team. + Add edge relay registers a new one; Install edge relay opens just the one-line installer; Refresh reloads the list.

Each row shows its address (or LAN address, for LAN-mode relays) and fingerprint, how many gateways and teams it's tied to, a LAN badge where it applies, a state badge (pending, active, revoked), and an online dot. A ▸ Topology disclosure above the Personal-tab table opens a canvas view of every relay's bridge links and routes.

Register → approve

1. + Add edge relay. Enter the hostname the relay will answer on (for example relay.example.com) and an optional display name.

   • Owner — if you manage any teams, pick Personal or one of them; a team edge counts against the team's quota, not your personal limit.
   • Mode — Frontier (public, TLS on port 443 by default) or LAN (serves clients on the local network directly, TLS on port 8448 by default; the hostname can then be a .local mDNS name or LAN IP, and a public domain is optional).
   • TLS port — optional; leave blank to use the mode's default.

2. Click Create. The console mints a one-time setup blob and PIN (shown once, with an expiry — mint again if it lapses), plus the full command:

   burrowee edge bootstrap <blob> <pin>

   Run it on the relay machine. The relay enrols and appears in the list as pending.

3. Click Approve, which appears once the relay has posted back its identity. The relay flips to active and starts serving. Approval counts against your plan's (or your team's) edge-relay limit.

The pending step is deliberate: a blob could be run anywhere, so nothing serves your traffic until you confirm the enrolment you expected. A pending relay that hasn't posted back yet can have its pairing material regenerated from the row's [≡] menu if the original blob or PIN was lost.

Wiring a relay to a gateway

An active relay carries only the gateways you connect to it. Open the row's [≡] menu and click Pairing — the console mints a one-time blob + PIN, with tabs for Pair Gateway (burrowee gateway relays pair <blob> <pin>, or paste it into the gateway's local console under Relays → Pair) and Pair CLI (burrowee cli relays pair <blob> <pin>, run on the machine where burrowee cli is installed). The blob expires; mint again any time. The relay's Gateways detail tab lists everything currently riding it, each a link to its gateway page.

Team ownership and sharing

An edge relay can belong to a team from the moment you create it (the Owner picker above), or you can move a personal one in later:

• Share (row menu, manager+) opens the relay's Teams detail tab (below), which lists the teams this relay is currently shared into — each with your role and the team's gateway count — and, for managers, a Remove per team plus a picker to add another team you belong to. Sharing is many-to-many — one edge can serve several teams at once — and each team only sees the relay, not each other's routes over it.
• Move to team… (personal relays, manager+) transfers ownership outright: pick one of the teams you administer. This is one-way from the console; the relay's creator can Move to personal… to bring a team-owned edge back.
• Your plan (or the team's) caps how many active, serving edge relays an owner may have; going over the cap at route-create time is either blocked or billed, depending on your plan — see Billing. Disabled routes don't count against the cap.

The relay's detail tabs

Click an active relay's row to expand its tabbed detail:

• Addressing — the relay's address, and, for edge relays, editable mode and TLS port fields.
• Bridge links — the bridge-links panel, route composer, and live flow view for edge-to-edge bridging: which edges this one links to, staged and live routes, and a flow diagram of traffic passing through the chain.
• Gateways — every accessible destination this relay can reach: gateways bound directly to it, plus gateways reachable through its active bridge links (each tagged via <edge>). Direct rows carry a ↻ Resync (re-push that gateway's config/routes/certs/bridges to this edge) and a ✕ Remove (unbind it), and a chip showing whether the gateway is currently syncing through this edge. When the relay is shared, destinations outside your visible scope are summarized as a "N not visible" count rather than listed.
• Teams — sharing (shown when the edge is shared into a team or you can manage it): the teams it's shared into, each with your role and the team's gateway count; managers get a per-team Remove and an add-a-team picker. A team-owned edge is never offered back to its owning team.
• Health — a read-only view of the relay's connection counts and resource headroom, refreshed every 10 seconds.
• Endpoints — LAN-mode relays only; see below.
• Update — push a version update to the relay through the console. A readiness panel shows the two independent conditions a push depends on: cloud push opt-in (allow_push_update) and updater agent connectivity — whether the standalone updater agent has heartbeated recently (with its last-seen time and version). A push is refused unless both are green, so a node can be online with push enabled yet still refuse because its updater agent isn't running.

Endpoints — reported vs published

A LAN relay discovers its own addresses and reports them up to the console. Reported addresses are candidates; nothing changes for your devices until you publish them. The Endpoints tab shows both sets:

• Reported — what the relay currently sees (wss://<ip>:<port>), with a published badge where applicable. Hide an address you never want offered (a guest network, a VPN interface); hidden entries sit under Show hidden and can be unhidden later.
• Published — the addresses your gateways and CLI pairings actually use.

When the relay reports addresses that differ from what is published, the row shows a New LAN addresses reported banner with an Update endpoints button. Publishing pushes the new addresses to connected gateways automatically (or they pick them up on their next sync). CLI clients keep their old addresses until updated manually — re-run burrowee bootstrap on the client, or edit its config.

Deactivate and delete

From the row's [≡] menu:

• Deactivate (on an active relay) revokes it permanently: it stops serving, and the slot frees up for a replacement. There is no un-revoke — add a new relay to replace it.
• Delete (on a pending or revoked relay) erases the row entirely, including its dependents. An active relay must be deactivated first.