This page explains the three foundational objects used to model ownership and isolation in Nanami.
Workspace
A workspace is the top-level boundary.
It scopes:
- users,
- groups,
- networks,
- nodes and gateways,
- roles and settings.
Diagram (text)
Workspace -> Groups -> Networks -> Nodes/Gateways
Relation to other concepts
- Every group belongs to exactly one workspace.
- Every network belongs to one group and one workspace.
- Access decisions are evaluated within workspace scope first.
Group
A group is an ownership unit inside a workspace.
Typical mappings:
- platform team,
- product squad,
- environment team,
- regional operations unit.
Groups help avoid policy sprawl by giving each team a clear operational area.
Diagram (text)
Workspace (acme) -> Group (platform) -> Networks (prod-eu, prod-us)
Relation to other concepts
- Networks are attached to groups.
- User access can be delegated at group scope.
- Incident response and change ownership are easier when groups reflect real teams.
Network
A network defines a private address space and policy context.
Each network has:
- a name,
- a CIDR,
- status/lifecycle state,
- membership relationships to nodes.
Diagram (text)
Group -> Network (10.42.0.0/16) -> Node memberships
Relation to other concepts
- Node membership is evaluated per network.
- Routing policy (ingress/egress behavior) is defined per network and can be overridden.
- Gateway and gateway selection decisions are made in network context.
Practical modeling guidance
- Start from ownership, not from IP ranges.
- Create groups that mirror real operators.
- Add networks per environment/region with non-overlapping CIDRs.
- Keep naming and ownership consistent before scaling node count.
Anti-patterns to avoid
- One giant network for all teams.
- Groups that do not map to any real operational ownership.
- Overlapping CIDRs across networks unless you have a deliberate translation strategy.