Team & roles

The Team page (/team) is where you share your account with other people — teammates, hired sysadmins, agency developers, or end customers who only manage their own site. Every person gets a role (what they can do) and a scope (which servers or sites it applies to). Inviting members needs a paid plan: Plus includes 1 teammate seat, Pro 5, and Max up to 99.

Invite a member, step by step

1. Click Invite member (top-right — visible to the account owner only).
2. Enter the person’s email address. They don’t need an account yet; the invite creates one tied to that email.
3. Pick a Role. The picker opens a card list — each role shows what it can do and whether it’s account-wide or scoped. See Roles & scopes below.
4. Set the Scope. Account-wide roles (Admin, Billing) can’t be narrowed. Scoped roles (Operator, Developer, Client, Site admin, Read-only) show a searchable checklist of your real servers or sites — tick the ones this person may touch. A scoped member with nothing selected sees nothing, so pick at least one.
5. For shell-capable roles (Admin, Operator), optionally flip the Allow shell / root file access toggle. This is never implied by a role — it’s an explicit per-member grant, because it bypasses every other guardrail.
6. Click Send invite. MZPanel emails the person an invite link and shows you a copyable share link as well. They join once they sign in with that email and accept.

Accepting an invite

The invite link signs the person in, then shows an Accept box. It only works for the exact email you invited — someone signed in as another address can’t claim it. Until they accept, they show as Invited in the roster.

What else you can do

The page is a searchable roster of member rows, plus two side drawers:

• Search members — filter the roster by name, email or role.
• Roles — opens a drawer explaining every role, its capability groups, its allowed scope kinds, and whether it’s shell-capable. This is the legend behind every assignment.
• Activity — opens the account audit trail: real control-plane events (sign-ins, member changes, dispatched jobs) with filters by category, actor and date range, and an expandable detail (action, target, IP, user agent, raw metadata) per row.
• Edit a member — click a row (or the pencil) to change their role, scope or shell toggle.
• Suspend / reactivate — freeze a member’s access without deleting them; their seat is freed while suspended.
• Resend / copy invite link — for a pending invite, re-email it or copy a fresh share link (both rotate the token, so the copied link is always valid).
• Remove — take a member (or a pending invite) off the account entirely.

The owner is always listed first, is non-removable, and holds every capability.

Roles & scopes

A role is a fixed preset of capabilities — you don’t edit a per-permission matrix, you pick a role. A scope decides which resources it covers. A member is a role × scope, plus an optional shell toggle.

Role	What they can do	Scope	Shell-capable
Owner	Everything, including billing, members and integrations	Account-wide	Yes
Admin	Full technical control of every server; no billing, no member management (can view the team)	Account-wide	Yes
Operator	Fully manage & administer the servers they’re assigned — like a hired sysadmin	Servers	Yes
Developer	Build, deploy and configure the sites/servers they’re assigned; no system administration	Sites or servers	No
Client	Run their own site — content, plugins, cache and stats; never sees the server	Sites	No
Site admin	A Client, plus their own site’s SSL certificate and PHP version	Sites	No
Billing	Invoices, plan and payment methods only; no technical access	Account-wide	No
Read-only	View-only within the assigned scope; cannot change anything	Any	No

Owner is a reserved singleton — it’s not offered in the invite picker; the other seven are assignable.

Account concerns are never delegated

Billing, adding or removing servers, and integration credentials (DNS tokens, AI keys, backup-destination secrets) stay with the owner. No technical role reaches them, and sealed credentials stay sealed. An Admin can view the team but can’t invite or edit members.

Per-site access (share-host)

The Client and Site admin roles power the share-host experience: you hand a single website to a customer without exposing the rest of the server.

• A site-scoped member sees only their own site(s) — no server list, no sibling 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 merely hidden in the UI.
• Site admin adds the two per-site ops a technical customer usually needs — issuing their own SSL certificate and switching the site’s PHP version — without any server-level reach.

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

How it works

Everything on this page is real and control-plane only — it drives the /v1/team/* API, not an agent on a box:

• The roster is GET /v1/team/members. The owner is synthetic (resolved from the org’s owner_user_id, not a membership row) and always first. Each other member is an org_members row; their scope lives in member_scopes (server rows, or server+domain rows for site scope).
• Invite (POST /v1/team/invite) finds-or-creates a user by email, writes an invited membership with a hashed one-time token, sets the scope rows, and emails the link. Accepting is a magic-link sign-in that flips invited → active.
• Edit / suspend / reactivate / resend / remove map to PATCH and POST /…/suspend /reactivate /resend and DELETE /v1/team/members/:id. Every action writes an audit_logs entry — that’s exactly what the Activity drawer reads back.
• Enforcement runs on every request: the API resolves the caller’s effective grant (role + scope + shell) and checks it against the resource — coversServer for a whole box, coversSite for one domain, and a section→capability map for each server page. Site scope deliberately does not widen to the host server, so a Client never leaks a sibling site’s data.

Seat limits are per tier — free 0, Plus 1, Pro 5, Max 99 (suspended members don’t count against the limit).

API & automation

Team management is an account-level, control-plane feature, so the on-box mz CLI does not apply here. Everything the page does is available over the REST API under /v1/team/* for scripted onboarding/offboarding. See the API reference (programmatic access is a Max plan feature).

Gotchas & troubleshooting

• The page is owner/admin only. A member without members.view gets a “Team is owner-only” screen. Only the owner can invite, edit, suspend or remove; an Admin can view the roster and activity but not change it.
• On a free plan you can’t invite anyone. The roster shows just you with a Pro upsell banner; the Invite member button is disabled until you upgrade to Plus or higher.
• Seat limit reached? Remove or suspend a member to free a seat, or move up a tier — Plus 1, Pro 5, Max up to 99. Suspended members don’t consume a seat.
• No ownership transfer / no workspace switcher yet. There’s one workspace per account, and true member-to-member ownership transfer is deferred. To hand the whole account to someone, change the account email to theirs; to let a colleague co-run it, invite them as Admin.
• The shell toggle is separate from the role. Even Admin and Operator don’t get root terminal / raw file write unless you explicitly enable Allow shell on that member. Non-shell roles never show the toggle.
• Invite email didn’t arrive? The membership is still created — open the pending row and use Copy link or Resend invitation; both rotate the token so the newest link is the valid one.

Related

• Security model — how auth, sessions and the audit log work.
• Plans & billing — seat counts and what each tier unlocks.
• API reference — scripting team changes on the Max plan.