Teams & roles

A team is the unit of ownership and collaboration on managed.dev. It groups the people you work with and the sites you run, holds the plan and billing relationship, and is the boundary that every permission check resolves against. Each person on the team holds a role, and that role decides what they can see and do. If you sign up solo, you already have a team of one — you’re its owner.

Sites are organized into projects inside a team, which lets you scope a person’s access to a subset of sites. Roles describe what a member can do; projects describe where they can do it.

Roles

managed.dev uses role-based access control with five roles. Pick the least privileged role that lets someone do their job — you can always promote later.

Role	What it’s for	Can do
owner	The team’s responsible party. There is exactly one at a time.	Everything admin can, plus transfer ownership, delete the team, and change the plan.
admin	Day-to-day team and infrastructure management.	Manage members and invites, projects, sites and environments, deploys, domains, security and observability config. Cannot transfer ownership or delete the team.
site_manager	Operators who run sites but don’t manage the team.	Deploy, manage environments, snapshots, domains, plugins/themes, and read observability — on the sites or projects they’re granted. No member or billing management.
observer	A read-only seat.	View sites, environments, observability, security, and audit data. Cannot deploy, change config, or manage members.
billing	Finance and procurement.	View and manage billing, invoices, payment methods, and the plan. No access to site config or deploys.

The observer role is a read-only seat

An observer is a true read-only member — useful for a client who wants visibility, a contractor doing a review, or a stakeholder watching observability without the ability to touch anything. Grant it freely; it can’t change state.

These same roles flow through to the public API: an API key can never exceed the RBAC role of the person or service that owns it. A key is always forced to Role=client, and effective permission is the intersection of the owner’s role, the key’s scopes, and any resource constraint. See the security model for the full down-scoping rule.

Inviting members

1. Open Team → Members in the dashboard and choose Invite member.
2. Enter the person’s email, pick a role, and optionally scope them to specific projects rather than the whole team.
3. Send the invite. They receive an email — delivered by our managed transactional mail — with a link to accept and set up their login.

The Team → Members screen in the app.managed.dev dashboard, listing members with their role badges, a pending invite row, and an “Invite member” button.

Invites are pending until accepted and can be revoked at any time. A member who hasn’t accepted holds no permissions.

Transferring ownership

Every team has exactly one owner. To hand it off, the current owner promotes another member — typically an existing admin — to owner. Ownership transfer is the only action reserved entirely to the owner, alongside deleting the team and changing the plan.

Ownership is singular

Transferring ownership demotes the previous owner to admin. Make sure the new owner is the right person before confirming — they inherit control of billing and the team itself.

What every member shares

Regardless of role, members of a team see the same set of sites and environments that their role and project scope allow, log in with magic-link SSO into wp-admin without sharing passwords, and have their actions recorded in the audit log.

ProjectsGroup sites and scope a member's access to a subset of them.

Audit logSee who did what, where, and when across the team.

Plans & limitsWhat your plan includes and how per-account overrides work.

Teams in the APIManage members, projects, and invites programmatically.