Team management

deploymill workspaces are organizations — every app, domain, database, and secret belongs to an org, not to an individual. You can invite teammates into your org, give them roles that scope what they can do, and manage who's in the workspace from the dashboard at /account/org.

Team management is part of account & org management, which is API-first rather than agent-first by design: deploymill puts deploying on the MCP tool surface, but running the workspace itself — members, roles, invites, seats, SSO — is human work, so it lives in the dashboard, not the MCP tools. You'll do all of it from the Organization settings page. It's still fully programmable: the same actions are exposed over deploymill's API (the Better Auth organization and invite routes behind /account/org), so scripts and tooling can manage the team without a browser — there just isn't (and doesn't need to be) an MCP tool for it.

Roles and what each can do

Every member has exactly one role in the org. Roles are ranked — a higher role can do everything a lower one can, plus more:

A couple of things worth calling out:

• Owner is the top role. There is always at least one owner (see the

  last-owner rule below), and only an owner can hand out or take away the owner role, or erase the workspace.

• Admins handle day-to-day team management — invites, removals, role changes

  — and the destructive app/secret operations, but they can't touch ownership.

• Members are the safe default for most teammates. They can ship and operate

  apps (deploy/start/stop) and read everything, but can't delete apps, manage secrets, or change the team.

• SSO and domain configuration are operator-managed, not something even an

  owner self-serves from the dashboard — see the SSO setup doc for how that works.

These roles apply equally to the MCP tools and the dashboard. If an agent calls a tool it isn't permitted to run, the tool fails with a structured not_authorized error that names the role required, so the agent can ask an admin or owner to perform that step rather than dead-ending.

Inviting a teammate

From /account/org (you must be an admin or owner):

1. Enter the teammate's email address and pick the role to grant. You can invite

   someone as a member or an admin — owner is never invitable; it's granted after the fact by an existing owner.

2. Send the invite. deploymill emails them a single-use invitation link that is

   valid for 7 days.

3. The teammate clicks the link, signs in (or signs up), and is added to your

   org with the role you chose. The link can only be used once — if it expires or is already used, ask an admin to resend it (a fresh link is issued, and the old one stops working).

Invites require email to be configured for the deploymill instance. If your operator hasn't set that up, the invite form will tell you it's unavailable.

Changing a member's role

On /account/org, admins and owners can change any member's role between member, admin, and owner — with one restriction: only an owner can grant or remove the owner role. An admin can promote a member to admin (and demote an admin back to member), but promoting someone to owner, or demoting an existing owner, is owner-only.

Removing a member, and leaving an org

• Removing someone else is admin-gated. Removing an owner is owner-only.
• Leaving the org yourself is always allowed — unless you're the last owner

  (see below). Use this if you no longer want to be part of a workspace.

The last-owner rule

A workspace must always keep at least one owner. So the actions that would leave it ownerless are refused:

• You can't demote the only remaining owner to admin/member.
• You can't remove (or leave as) the only remaining owner.

If you're the sole owner and want to step back or leave, promote another member to owner first, then change your own role or leave.

Seats and the seat limit

Each org has a seat limit — the maximum number of members it can hold at once (the default is 10, and it's set by the deploymill operator; tenants can't raise their own ceiling). The /account/org page shows your current seat usage (e.g. "4 / 10").

When the org is at its seat cap:

• Sending a new invite, and accepting one, are both refused with a

  seat_limit_reached error.

• To make room, remove a member (freeing a seat), or ask the operator to raise

  the limit.

The cap is checked at both invite-send and invite-accept time, so an org can never grow past its seat ceiling even if several invites are outstanding.

Where to go next

• SSO setup — single sign-on, domain auto-join, and SSO

  enforcement for your org.

• deploymill://guides/secrets — managing the org-scoped secret vault

  (admin/owner capability).