Skip to content

Edge-to-edge bridging

A bridge chains one edge behind another: an edge that can't take direct inbound traffic itself (no public IP, sits behind NAT, is only reachable from inside another network) subscribes to a public edge instead, and traffic reaches its gateways through that upstream edge as an extra hop. From a client's point of view the chain is invisible — you dial the gateway's advertised entry edge exactly as you would a directly-paired one; which edges the route actually passes through is resolved for you.

Trust between two edges is a local public-key pairing — independent of the console — while the routes (which chains exist, which gateways they carry) are still delivered to each edge the normal way, inside its console-signed configuration.

On the downstream edge (the one that will subscribe through an upstream edge):

sh
burrowee edge bridge key

Generates this edge's bridge keypair on first call (private key 0600, never leaves the machine) and prints its fingerprint — the identity the upstream edge needs to authorize.

On the upstream edge (the one accepting the subscription), authorize that fingerprint:

sh
burrowee edge bridge approve <fingerprint>

Prompts you to confirm the fingerprint out of band before writing it to authorized_keys — the same pairing-style confirmation as approving a gateway or CLI. Pass --yes to skip the prompt for a scripted/console-driven approval.

Back on the downstream edge, stage the Link:

sh
burrowee edge bridge subscribe <linkID> --addr wss://upstream.example.com --peer-fp <upstream-fingerprint>

--addr takes one of three forms:

FormFlagsUse for
Domain, TLS hostname-verified--addr wss://host:portAn upstream edge with a real certificate for that hostname (its frontier host, typically).
Plain, no TLS--addr ip:port --plainA trusted LAN/VPN hop where TLS isn't warranted.
IP, TLS pinned to a fingerprint--addr ip:port --cert-fp <fp>An upstream edge reachable only by IP — pins its certificate instead of verifying a hostname.

--plain and --cert-fp are mutually exclusive. This only stages the Link locally (under ~/.burrowee/edge/bridge/) — the daemon brings it up on its next config apply, or immediately on a SIGHUP/restart; it does not dial anything itself. A subscription can also arrive as a relation the console pushes down in the signed manifest, which is how the console's bridge-links UI drives this without touching either edge's CLI.

Inspect and remove

sh
burrowee edge bridge list

Prints the authorized inbound fingerprints (durable trust state) plus every staged/live Link, its address and mode, and its warm-pool depth.

sh
burrowee edge bridge remove <fingerprint>       # revoke an inbound trust
burrowee edge bridge remove --link <linkID>     # drop a staged outbound Link

A bare 16-hex argument is read as a fingerprint (revoke); anything else — or an explicit --link — is read as a LinkID (unstage). Either takes effect on the daemon's next SIGHUP or restart; the affected carriers tear down at that point, not instantly.

The isolated raw port

Multiplexed traffic over a bridge chain still passes through nginx like any other frontier connection. Isolated services — ones configured for a dedicated connection per client rather than sharing the multiplexed carrier — instead need a listener nginx never touches, since routing per-connection carriers through nginx would double-handle them and defeat the point:

sh
burrowee edge bridge raw-port           # print the current value (or "off")
burrowee edge bridge raw-port 8444      # bind it
burrowee edge bridge raw-port off       # disable it (the default)

Off by default. When set, the daemon serves the same handler on this port directly, unproxied — doctor checks both that it's reachable and that it's absent from the installed nginx config, flagging a misconfiguration either way. Setting it takes effect on the next restart.

Where next

  • Client-side: connecting through a bridged edge, gateways bridges, and --isolated are documented in Connect & SSH and Relays & gateways.
  • Console-side: the bridge-links panel, route composer, and live flow view are documented in Edge relays.
  • Operational health: the fd-limit and raw-port checks are part of doctor.