Private Mesh

Every Tabbify supervisor and running application joins a userspace WireGuard overlay. Tenant policy limits which peers are visible, and each application gets a stable IPv6 ULA derived from its UUID. Public application traffic enters through the managed edge rather than exposing the workload port.

The current production data plane is relay-only. WireGuard packets between platform and workload peers pass through the managed relay; the service does not currently promise a peer-to-peer production path.

Coordinator and joiner

The mesh has two roles. The coordinator registers peers, assigns peer addresses, and returns an ACL-filtered roster. The joiner runs with each platform node or workload runner, opens a TUN device, and maintains the WireGuard session used for relay transport.

# Local coordinator example
tabbify-mesh-coordinator --bind 0.0.0.0:8888 \
  --tls-cert ./coord.crt --tls-key ./coord.key --tls-ca ./ca.crt \
  --policy-file ./acl.json --auth-url http://localhost:8080

# Joiner - the managed coordinator address is built into the distribution
tabbify-mesh join --name supervisor-01 --tag supervisor --tag firecracker \
  --tls-cert ./peer.crt --tls-key ./peer.key --tls-ca ./ca.crt \
  --join-token $MESH_JOIN_TOKEN

The managed coordinator address is built into the distributed joiner, so a managed node normally does not need an endpoint flag. Override it only for local development with --coordinator or TABBIFY_MESH_COORDINATOR.

Peer and per-app ULAs

Addresses come from two blocks. Platform peers get fd5a:1f00::/32. Apps get their own address fd5a:1f02:XXXX:XXXX:XXXX:0:0:1, where the three XXXX groups are the first six bytes of blake3(app_uuid) taken as three big-endian u16s — for example, UUID 0191e7c2-1111-7222-8333-444455556666 derives fd5a:1f02:44a5:240b:121a::1. The supervisor and edge compute the same address, so the application route remains stable across deployments. Supervisors advertise the app-ULAs they host on each heartbeat (POST /v1/mesh/heartbeat), and receiving peers install /128 routes so dialing [app_ula]:8730 reaches the right host.

{"peer_id":"<uuid>","ula":"fd5a:1f00:0000:0001::1","display_name":"supervisor-01",
 "tags":["supervisor"],"hosted_app_ulas":["fd5a:1f02:44a5:240b:121a::1"]}

There is no per-request application-to-host lookup. The edge computes derive_app_ula(uuid) and sends traffic to [app_ula]:8730; the installed mesh route carries that traffic through the relay to the selected supervisor.

Production transport

Joiners maintain a persistent connection to the managed relay at https://relay.tabbify.io. This gives hosts behind firewalls or NAT a consistent path without opening the application's guest port. The relay is part of the current production path and must be included in latency, capacity, and failure planning.

Encryption and access control

WireGuard encrypts mesh packets. Join tokens and tag-based ACL policy determine which peers enter a tenant network and which roster entries they can see. A policy change causes peers to refresh their visible roster.

Certificate options also exist for coordinator connections:

tabbify-mesh-ca init --out ./mesh-ca
tabbify-mesh-ca issue-peer --name supervisor-01 --ca-dir ./mesh-ca --out ./certs

Certificate use is not uniform across every platform hop today. Do not treat mesh encryption or peer visibility as application-level authorization; services must still validate callers and protect sensitive routes. Join-token claims, not self-declared peer tags, are authoritative in the managed network. See Auth & join tokens.

See self-hosting a node to join a machine to the mesh.