Skip to main content

​
Organization Members

You can invite someone to join your organization by email. Once they accept the invitation, they will have access to the organization and all its projects based on their assigned role.

​
Accessing Members Settings

1

Open Organization Settings

Click the Settings tab while you are on your organization overview.
How to access your organization settings
2

Navigate to Members Section

Open the Members section within the organization settings
Qovery - List all members within an organization

​
Inviting Members

  1. Click the Invite Member button
  2. Enter the member’s email address
  3. Select a role (see Default Roles below)
  4. Click Send Invitation
The invited member will receive an email with instructions to join the organization.
Each user can only hold one role at a time. Changing the role of a member requires the user to logout/login to make the changes effective or wait a few minutes (max 1 hour).

​
Default Roles

Qovery provides 5 built-in roles with predefined permissions that apply across the entire organization.

​
Owner

Full access to the organization. Only one user can be the owner, and ownership can be transferred (see below).

​
Admin

Same as Owner except cannot delete the organization or transfer ownership.

​
DevOps

Can manage organization infrastructure (clusters, registries, webhooks, API tokens) and has full access to all projects and environments across the organization. Cannot manage members, roles, or billing.

​
Billing Manager

Can manage billing only. Has read-only access to cluster information but no access to any project.

​
Viewer

Read-only access to all organization resources, clusters, and projects.

​
Default Roles - Permissions Matrix

​
Custom Roles

Custom roles let you grant access scoped to specific projects and clusters, instead of applying permissions across the entire organization. This is useful when you want to give a user access to only certain projects or restrict what they can do within a project.

​
Scope and limitations

Custom roles are configured through cluster-level and project-level permissions only. They always inherit the ability to read organization data (registries, clusters, label groups). Custom roles cannot:
  • Generate API tokens
  • Manage organization settings (webhooks, SSO)
  • Manage members & roles
  • Manage billing
If a user with a custom role needs to generate an API token (e.g. for the CLI or Terraform provider), an org admin or DevOps user must generate it for them.

​
Cluster Level Permissions

Set individually for each cluster. A cluster created after the role is configured starts with Read-Only access:

​
Project Level Permissions

Set per project, independently for each environment type (Development, Preview, Staging, Production):

​
Shell and Port-forward Permissions

Remote access to the running services is granted separately from the level, with two permissions set per project and per environment type:
  • Both can be granted from Read-Only up, for example to let a user port-forward to a database without being able to deploy.
  • Neither can be granted with No Access.
  • Full Access on a project always includes both.
  • They are independent: a role can deploy to Production without being able to open a shell there.
Custom roles created before these permissions existed have both enabled on every environment type where their level is Deploy or above, so their access did not change.
When a permission is missing, the connection is refused.

​
Custom roles vs built-in DevOps role

A custom role configured with Full Access on all clusters and Full Access on all projects covers the same day-to-day operations as the DevOps role, but with two differences: it cannot generate API tokens or manage org-level settings, and it can optionally be scoped to specific projects only.

​
Example configurations

Developer - access to a specific project A developer who should deploy and configure services in one project but have no visibility into other projects: On-call engineer - deploy to any project, no config changes An engineer who needs to trigger deployments and read logs across all projects in an incident, but should not be able to modify service configuration: Deployer without shell access in production A developer who deploys to every environment type and can debug Production through port-forward, but cannot open a shell there: Security auditor - read-only across everything A user who needs visibility into all environments for audit purposes: Infrastructure-as-code operator - manage a specific environment A user running Terraform or similar tooling against a single environment (API token must be generated by an admin):

​
Transfer Ownership

You can transfer ownership of the organization to another member. To do so:
  1. Navigate to the Members section in organization settings
  2. Click on the member you want to transfer ownership to
  3. Select Transfer Ownership from the menu
  4. Confirm the transfer
Once ownership is transferred, you will no longer be the owner of the organization.