Team management

DeployMill workspaces are organizations: every app, domain, database, and secret belongs to an org, not to an individual. From the Organization settings page at /account/org you can invite teammates, give them roles that scope what they can do, and manage who's in the workspace.

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 rather than the MCP tools. 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, so a higher role can do everything a lower one can, plus more. These are the defaults: an admin can fine-tune individual capabilities per member on top of their role (see Fine-tuning a member's permissions below).

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.

Fine-tuning a member's permissions

Roles set the default capabilities, but you don't have to accept them wholesale. From /account/org, an admin can grant or revoke individual capabilities for a specific member on top of their role. For example, revoke secret management from one admin, or let a trusted member delete apps without promoting them. A member's effective access is their role's defaults plus any grants, minus any revokes (a revoke always wins). You can only grant a capability you hold yourself, and changing ownership stays owner-only.

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

Seats are free and unlimited on every plan, including the free Explore tier. Under uptime pricing you pay for the hours your apps are awake, not for how many people are in the workspace, so there's no per-seat fee and no seat cap to bump into. Invite as many teammates (and connect as many agents) as you need; neither sending nor accepting an invite is ever refused for running out of seats. The /account/org page shows your current members.

Seats remain an Enterprise governance surface only (SSO/SAML/SCIM and role/approval policy), never a sold quantity.

Per-member app limits

Beyond the org-wide app quota, an admin can cap how many active apps an individual member may run, from /account/org. The effective ceiling for a member is the smaller of the org quota and their personal cap (min(org, member)), and the members roster shows each member's usage as "N / M apps". A deploy that would put a capped member over their limit is refused with a member_app_limit_reached error (distinct from the org-wide active_app_limit_reached), while other members are unaffected. Leave a member's cap unset for no personal limit, and the org quota alone applies.

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).