Role-based access control (RBAC) in dotEnv Cloud lets you grant each team member exactly the access they need, no more, no less. Roles are assigned per organization, so the same person can hold different roles across the organizations they belong to.
How roles work
Every membership ties a user to an organization through a role. The role determines what that member can see and do: who can manage projects and secrets, who can invite others, who can change billing, and who has read-only visibility. dotEnv Cloud ships a set of built-in system roles that cover the common cases.
The system roles
Out of the box, dotEnv Cloud defines seven system roles, ordered roughly from most to least privileged:
| Role | Typical use |
|---|---|
| Owner | Full control of the organization, including ownership transfer and deletion. |
| Administrator | Manage projects, secrets, members, and teams: everything except billing. |
| Developer | Work with projects and secrets day to day, without member or billing administration. |
| Member | General access to the organization's resources for collaborators. |
| Auditor | Read-only access focused on reviewing activity and the audit log (no secret decryption). |
| Billing Manager | Manage subscription, payment methods, and invoices. |
| API User | Limited, read-only access for integrations: read and decrypt secrets, nothing else. |
Assigning roles
Invite a teammate from your organization's members settings in the dashboard and choose their role at invite time. You can change a member's role later from the same screen. Because roles are scoped to the organization, changing someone's role affects only that organization, not any other they belong to.
Choosing the right role
Apply the principle of least privilege:
- Give Developer to engineers who push and pull secrets but should not manage the team or billing.
- Reserve Admin for those who need to invite members and configure projects.
- Keep Owner to a small number of people, since it is the only role that can delete the organization or transfer ownership.
- Use Auditor for stakeholders who need read-only visibility into activity without the ability to change anything or decrypt secrets.
- Assign Billing Manager to finance contacts who manage the subscription but should not touch secrets.
- Reserve API User for machine integrations that only need to read and decrypt secrets.
API keys and roles
Organization API keys used by the CLI and SDKs act within the organization they belong to. Treat an API key like a credential with organization-level access: scope it carefully, store it as a CI secret, and rotate it if it may have been exposed. See Securing CI/CD Pipelines for key handling, and the Audit Logging guide to track who did what.