Team & roles

MZPanel shares access through a single workspace — the container that owns your servers, sites, billing, and the people you invite. You manage people from the Team page (/team).

The workspace model

Every account is a workspace. There is no separate “personal vs organization” choice:

• A solo user is a workspace with exactly one member (you, the owner).
• The workspace owns servers, sites, backups, invoices, the name, and the tier — everything hangs off it.
• Team is the people layer inside that workspace, not a parallel concept. Inviting someone means sharing your workspace.

Owner-only Workspace settings cover the container’s identity and lifecycle:

Action	Effect
Rename workspace	Changes the workspace name.
Transfer ownership	Handing the whole account to a successor is done by changing the account email to theirs; to let a colleague co-run it, invite them as Admin instead.
Close workspace	Type-name-to-confirm deletes workspace metadata (members, server records, jobs, backup metadata). Your VPS keep running and sites are never touched.

Note

There is one workspace per account and no workspace switcher today. True member-to-member ownership transfer (the multi-workspace model) is deferred. See docs/51.

Roles

A role is a fixed preset of capabilities; a scope decides which resources it applies to (the whole account, a specific server, or a single site). A member is a role × scope.

Role	Can do	Typical scope	Persona
Owner	Everything, including billing and team management	All	The account holder (one person, reserved)
Admin	Full control except billing and closing the workspace; can view Team	All	Right hand / co-runner
Operator	Manage one or more whole servers (sites, DB, PHP, services, OS, security, …)	Server	Hired sysadmin / devops
Customer	Manage only the site(s) handed to them — no server access, no sibling sites	Site	End customer / freelancer (share-host)

Account-level concerns — billing, adding/removing servers, and integration credentials (DNS tokens, AI keys, backup-destination secrets) — are never shared; only the owner touches them. Sealed credentials stay sealed.

Note

The terminal (root shell) is never tied to a role. It is a separate per-person toggle that only the owner/admin/operator may hold, because it bypasses every other guardrail.

Per-site access (share-host)

The Customer role powers the share-host experience: you hand off a single website to a client without exposing the rest of the server.

• A site-scoped member signs in straight into the per-site view of the site(s) they were granted.
• They see only their own site(s) — no server list, no other customers’ sites, no account navigation.
• They can run content and site operations on their own domain only; anything outside their scope is denied at the API, not just hidden in the UI.

Access shows up as a filter, not a disabled button: sections a member can’t use are removed from their navigation entirely, and the fleet list shows only the servers they were granted.

Plan

Team & RBAC is a Pro feature (multi-user share-host). Owner-side management (invite, roles, scopes, activity) and enforcement are built; some deep per-section guards are still being filled in. See docs/45 and docs/77 (§10).

Activity

Every shared action is recorded in the workspace Activity log — who did what, when, and the result. See Security model for how the audit log works.