Nanami architecture ties ownership, topology, and path intent into one operator surface.
This page shows how identity, gateways, networks, and routes become an inspectable control plane instead of a detached entity list.
Users, groups, networks, peers, gateways, and routes read as one system.
Topology is not detached from operational choices or runtime context.
Planned state and observed state stay visible together.
Control plane
Desired state and access intent
- Workspaces and groups
- Policies and join keys
- Identity and sessions
Gateway fabric
Regional orchestration and path stability
- Gateway manager
- Health reporting
- Runtime metadata
WireGuard data plane
Encrypted packet transport
- Peer config distribution
- Gateway selection
- Node-to-node traffic
The entity model is built for operator reasoning, not diagram theater.
Every object in the architecture contributes to an ownership, membership, or path-control narrative.
Users
Operators and members of the system. Access relationships need to stay visible instead of hiding in detached lists.
Groups
The ownership boundary for access scope, network membership, and operator filtering.
Networks
The context that makes route intent, peer membership, and gateway responsibility legible.
Peers
Runtime nodes with telemetry, connection posture, and attachment to the ownership model.
Gateways
Transit behavior stays explicit in the surface instead of becoming a hidden implementation detail.
Routes
Path control lives beside the networks and gateways it affects, so intent is easy to inspect.
The control plane explains both desired state and runtime transport behavior.
Nanami is structurally valuable because policy, gateway orchestration, and node enrollment read as one management flow.
Operational network view
Control intent, regional gateways, and enrolled nodes live in one architectural context.
Filter and isolate
Operators need to narrow the board by group, network, path type, or status without losing context.
Inspect desired vs observed
The entity model shows the difference between planned membership and live transport posture.
Move into action
The architecture surface leads into security review, docs, and the working environment without changing product language.
Need a control plane that explains the network before the first rollout?
Review the security model, open quickstart, or move into Nanami with the same architectural context.
Check quickstart
Docs turn the architectural model into a practical rollout sequence.
Planning a rollout?
Talk through migration constraints, deployment shape, and enterprise requirements with the team.