Access Control
Access on d2o PaaS works in two layers. Your organization role decides what you can do to the organization itself — its members, groups, projects, and settings. Your project capabilities, granted through groups, decide what you can do inside individual projects and their environments.
You manage all of this in the dashboard. The paas CLI can manage organizations, projects, and resources, but membership, groups, and invitations are dashboard features.
Organization roles
Every member of an organization has exactly one role:
| Role | What it grants |
|---|---|
| Owner | Full control of the organization, including deleting it and transferring ownership. Every organization has exactly one Owner. |
| Admin | Manage all members, groups, and projects. |
| Member | No project access on its own — Members reach projects only through the groups they belong to. |
The personal organization created for you when you join the platform is one you own. In a team organization, most people are Members whose actual project access comes from groups.
Project capabilities
Within a project, access is a set of individual capabilities — each one is granted separately, and you can hold any combination of them:
| Capability | What it grants |
|---|---|
| View | Read-only access — resources, log snapshots, and deployment status. |
| Promote & roll back | Promote releases into an Environment and roll apps back to an earlier version, and see build and release logs and follow live logs. |
| Deploy & operate | Push code and trigger deployments, see build and release logs, follow live logs, open a console on running instances, restart, and scale. |
| Manage web apps | Create, update, and delete web app resources. |
| Manage workers | Create, update, and delete worker resources. |
| Manage databases | Create, update, and delete database resources. |
| Manage object storage | Create, update, and delete object storage resources. |
| Manage secrets | Create, update, and delete secrets. |
| Manage environments | Create, update, and delete environments. |
| Manage project | Full control of the project, including its settings and invitations. |
Deployment tokens and GitHub/GitLab repository links follow the same capabilities: an Environment’s need Manage environments, and an app’s own need Manage web apps or Manage workers. Connecting a GitHub or GitLab account to the organization is limited to its Owners and Admins.
The dashboard offers presets — Viewer, Release manager, Developer, Maintainer, Admin — that select common combinations of these capabilities, so you don’t need to pick them one by one. A Release manager (View plus Promote & roll back) can move releases between Environments and undo them, without pushing code or touching running instances.
Owners and Admins automatically hold every project capability in the organization, apart from any capabilities the platform has reserved for its own operators. Members get capabilities only through groups.
Groups
A group is a named set of organization members plus a set of project grants. You create groups in the dashboard under your organization’s settings, add members to them, and then grant each group a set of capabilities on the projects it should reach (or start from a preset).
If you belong to several groups, your effective access to a project is the union of everything those groups grant you.
Per-environment overrides
A group’s grant applies to the whole project by default, but it can be overridden for specific environments. This lets you shape access per environment — for example, treating production differently from the project’s other environments — without splitting the project up.
Project guests
Sometimes you want to give one person access to one project without adding them to your organization at all — a contractor, or a collaborator from another company. That is a project guest.
Guests are added by inviting them directly to a project. The invitation carries the set of capabilities they will hold (organization invitations carry a role instead). A guest:
- has the granted capabilities on that one project, and nothing else in the organization;
- does not appear in the organization’s member list and cannot see organization-level pages — at most the organization’s name;
- is not affected by per-environment overrides — a guest’s grant is project-level only.
You cannot send a project invitation to an email address that already belongs to an organization member; existing members get access through groups instead. Project invitations can be sent by an organization Owner or Admin, or by someone who holds the Manage project capability on that project.
Because the platform is invitation-only, inviting someone who has never used d2o PaaS also creates their account — they receive an email that walks them through setting a password and accepting the invitation.
Next steps
- Groups & Project Permissions — create groups and grant project access step by step
- Inviting People — organization and project invitations in detail
- Managing Your Organization — members, roles, and ownership transfer
- Organizations, Projects & Environments — how the hierarchy fits together