Projects

A project groups sites within a team. It’s an organizational layer and an access boundary: instead of granting a member access to every site you run, you scope them to one or more projects. That makes projects the natural way to separate clients, business units, or environments that should never see each other.

A site belongs to exactly one project. Projects belong to exactly one team. The team holds the plan and billing; projects just slice the sites underneath it.

Why projects

• Organization. Once you run more than a handful of sites, a flat list stops scaling. Group them — acme-corp, internal-tools, client-work — and the dashboard stays navigable.
• Scoped access. Pair a project with a role from teams & roles to delegate cleanly. A site_manager scoped to the acme-corp project can deploy and operate Acme’s sites and nothing else.
• Delegating a client’s sites. Agencies put each client in their own project, then invite the client as an observer — or a contractor as a site_manager — scoped to just that project. The client sees their sites and observability, never anyone else’s.

Create a project

1. Open Team → Projects in the dashboard and choose New project.
2. Give it a name (and an optional description). The name is how it appears in the site list and in audit log entries.
3. Create it. The project starts empty — assign sites next.

The Team → Projects view in the app.managed.dev dashboard, showing three projects as cards, each with a site count and the members scoped to it.

Assign sites to a project

Every site lives in a project. When you create or migrate a site you pick its project; you can move a site to a different project later from the site’s settings. Moving a site is purely organizational — it doesn’t touch the site’s environments, domains, or data.

Delegating to a client

To hand a client’s sites over for review without exposing the rest of your account, put those sites in a dedicated project and invite the client scoped to it. Combine an observer role for read-only visibility, or site_manager if they need to deploy. See teams & roles for what each role can do.

Projects and access scope

A member’s effective access is the intersection of their role (what actions they can take) and their project scope (which sites those actions apply to). An admin scoped to one project manages that project fully but can’t see others; an unscoped admin manages the whole team. owner, by definition, sees everything.

This is the same model the public API enforces with resource constraints on a key — a project scope on a person mirrors a resource constraint on an API key. See account & teams in the API and the security model.

Teams & rolesThe roles you pair with project scope to delegate access.

Audit logProject context appears on every recorded action.