Team access & multi-tenancy
A planned, not-yet-built capability — assigning users to specific sites, nodes, or instances with a scoped role instead of one global role per user. This page records the decision, not shipped behaviour.
Planned — not shipped
Nothing on this page exists in the product yet. It documents a decision the operator has not made: whether to add per-resource team access. It's here so the tradeoffs are visible. Today's access model is what's described under Accounts — one global role per user.
Today's model
A user carries one global role:
admin— every permission, sees the whole fleet.operator— a fixed, read-mostly grant set, but still sees all sites, nodes, and instances.developer— zero panel access (an in-instance SFTP user, not a login).
There is no per-resource assignment. "Operator" always means the whole fleet. If you want to give someone access to just their sites, the panel can't do that today.
The question
Can we add users to nodes / instances / sites with different permissions — make people managers or owners of specific resources, limit what they see, and allocate monitoring per resource?
That's multi-tenancy of the control panel itself — a real fork in the road, because every screen that lists data would have to be limited to what each user is allowed to see, or it leaks.
Three honest options
Option A — Full per-resource grants (real multi-tenancy)
Assign a user to a specific site, node, or instance with a level (owner / manager / viewer). Every list and action is limited to what they're granted — a non-admin sees only their own resources.
- Buys: give a client access to their sites only; a teammate who manages a few nodes; per-resource monitoring; day-2 access without handing over the fleet.
- Costs: the largest, most security-sensitive change in the project. Every screen has to be scoped or it leaks, plus a new access layer and an assignment UI.
Option B — Site-members only (narrow multi-tenancy)
Membership on sites only (owner / manager / viewer per site). Nodes and instances keep the global role.
- Buys: roughly 70% of the value — "give a client their sites," "add a manager to a site" — for about 30% of the risk. Only the sites screens need scoping.
- Costs: still a real scoping pass, but a contained one.
Option C — Do nothing (stay single-tenant)
Keep one global role per user. Site handoff already lets you hand a site's credentials to an owner by email without giving them a panel login at all.
- Buys: nothing new, but nothing to break — and no risk of leaking the panel.
- Costs: every panel user still sees everything; no in-panel delegation.
Where this stands
If the near-term need is "let a client manage their own sites," the recommendation is Option B — the 80/20 that doesn't touch the node/instance access the whole fleet's safety rests on. But no option is chosen yet, and for many "give the client access" needs, emailing credentials plus a deploy/SFTP key (which already works) is enough.
When a direction is picked and built, this page will be replaced with the real feature docs.