Search docsFilter pages by title

Nodes, gateways, and transport gateways

Nanami separates routing-capable gateways from transport gateways.

Node

A node is a data-plane participant in one or more tenant networks.

Node records include identity material (public key), status, endpoint metadata, and network memberships.

Network Gateway (current)

A Gateway is a WireGuard node that can route traffic for one or more tenant networks.

Gateway behavior in MVP:

  • tenant-scoped by default,
  • can participate in ingress/egress and exit-node routing,
  • receives desired state from gateway-manager,
  • applies interfaces/routes/NAT through gateway-daemon,
  • can be assigned automatically (auto, balanced) or manually (coming soon UI controls).

Diagram (text)

Client -> Gateway -> Private network resources

Gateway manager and gateway daemon agents

Nanami currently uses two runtime agents:

  • gateway-manager (compat: gateway-manager): desired/observed control loop.
  • gateway-daemon (compat: gateway-daemon): local runtime apply and telemetry.

Diagram (text)

Control plane -> gateway-manager -> gateway-daemon -> observed state -> control plane

Transport Gateways (future, coming soon)

Transport gateways are planned as connectivity fallback only (DERP-like), not routing gateways.

Planned properties:

  • stateless forwarding layer,
  • safe to share across tenants because no route ownership,
  • no tenant AllowedIPs/route/NAT control.

Diagram (text)

Client A <-> Transport Gateway (future) <-> Client B

Why this split matters

  • Gateways route and can be tenant-sensitive.
  • Transport gateways only improve reachability and should not become policy routers.
  • This keeps cross-tenant safety and operator mental model clear.

TODO roadmap hooks

  • Shared transport gateway implementation (DERP-like).
  • Multi-hop routing chains and policy-based pathing.
  • Gateway redundancy policies (redundancy: 2+).
Edit this page