Organization

An organization is a shared account where developers can collaborate across many projects at once. Owners and organization administrators can manage:

  • cloud accounts.
  • members access.
  • the billing.

Creating an Organization

When signing up for Qovery, you need to create an organization. You can choose between 4 plans: Free, Professional, Business and Enterprise:

Qovery Pricing Plans

For more information, see our pricing page.

Once you have chosen a plan, you need to sign in through your Git provider (Github, Gitlab or Bitbucket). Your organization is then created.

To manage your organization settings from the Qovery Console, click the cogwheel icon on the top right of the screen:

Organization Settings Access

In the General Information tab:

Organization Settings Access

  • Company name: enter the name of your company.
  • Description: enter a description of your organization.
  • Website: enter the website of your company.
  • Admin contact emails: enter one or several email adresses (separated by commas) on which you want to receive important communications from Qovery.

Don't forget to click Update to save your organization information!

Managing your clusters

With Qovery, you can manage multiple clusters in your organizations settings. You can then deploy your project environments and services to the cluster of your choice.

In the settings of your organization, you can add, stop and delete a cluster, as well as update its settings.

Qovery - Manage multiple clusters in your organization

For more information, see Clusters.

What is the default cluster?

The default cluster is the first cluster you installed in your organization.

When you create a new environment and leave the mode and cluster parameters set to the value Automatic, your environment is deployed to:

  • the cluster defined in one of your project rules,
  • or to the default cluster if no project rule applies.

For more information on deployment rules, see Project.

Organization members

This section allows you to manage the members of your organization (add / remove) and as well assign a role to each of them.

You can invite someone to join your organization by email. Then he will get access to your projects and will be able to contribute.

Qovery - List all members within an organization

Roles-Based access control (RBAC)

Qovery allows you to control the access to your cluster and environment resources by defining and assigning roles to your users.

By default, five roles are created within your organization (Basic Roles):

  • Owner: the user has full access on the organization
  • Admin: same as the owner, the has full access to the organization but he cannot delete it
  • DevOps: the user can manage the organization infrastructure (clusters/registry/webhook setup) and manage the deployments of any environment within the organization.
  • Billing Manager: the user can only manage the billing of the organization
  • Viewer: the user has read-only access to any section of the organization

More in detial, you can find the associated permissions below:

ActionOwnerAdminDevOpsBilling ManagerViewer
Read organizationyesyesyesyesyes
Edit organizationyesyesnonono
Delete organizationyesnononono
Manage billingyesyesnoyesno
Manage members & rolesyesyesnonono
Manage cluster & contrainer registryyesyesyesnono
Manage organization setup (webhooks, API tokens etc..)yesyesyesnono
Read ANY projectyesyesyesnoyes
Edit/Delete ANY projectyesyesnonono
Create projectyesyesnonono
Read ANY environmentyesyesyesnoyes
Edit/Delete ANY environment or serviceyesyesnonono
Create environment or serviceyesyesnonono
Deploy/Stop ANY environment or serviceyesyesyesnono
Connect via SSH to ANY applicationyesyesyesnono

Custom roles

If the basic roles are not enough given your internal organization, Qovery allows you to customize the accesses to your clusters, projets and environments by defining Custom Roles.

To create a custom role, go in the Roles & Permissions section press "Add new Role"

For the new role, you will be able to specify:

  • The name of the role
  • A description
  • Cluster Level Permissions: in this section you can fine tune the access to the computing resources. For each cluster of your organization, you will be able to specify an access permission (ordered by permission level):
NamePermission Type
Read-OnlyThe user can access the cluster information (name, region etc..). Minimum permission level.
Create EnvironmentThe user can create environments on this cluster. Only users with this role could allocate resources for their environments on this cluster. Further environment level permissions (like deployment rights) are managed via the "Project Permissions", see below
Full AccessThe user can create create environments on this cluster and as well manage the cluster's settings (start/stop, change number and type of nodes etc..). This permission allows a group of users to manage by themselves a specific cluster
  • Project Level Permissions: this section allows you to fine tune the access to the projects and their environments. The environment access is managed by "Environment Type" to simplify the configuration (Production, Staging, Development, Preview). For each project of your organization and by environment type, you will be able to specify an access permission (ordered by permission level):
NamePermission Type
No AccessThe user has no access to this environment type. If the user has "No Access" on all the environment types, he will not have access to the project
Read-OnlyAccess in read-only to this environment type. Useful to restrict access on sensitive environments
DeployManage the deployments of this environment type, access the logs, connect via SSH to the application and manage its environment variables
ManageManage the deployments and the settings of this environment type (including adding or removing services)
Full AccessThe user is admin of the project and can do everything he wants on it (no matter the environment type)

Qovery - custom role

Once the role is created, you can assign it to a member of your organization within the "Members" section. You can also update the permissions by editing the role from the Roles&Permissions screen

Examples

Within this section, we will try to provide you some example of roles & permission setup

Example 1, simple setup: An organization has 3 clusters ("prod cluster", “staging cluster”, “dev cluster”) and 1 project P1. The organization has a CTO, a devops and some developers. The roles & permissions could be configured in this way:

  • CTO = Owner
  • Devops = Devops or Admin
  • Developers: we want these users capable of accessing the project, having read access to the prod clusters/env, managing deployments on the staging cluster (but not creating new environments on it) and doing whatever they want for the development environments on the dev cluster. So the configuration will look like:
    • Create a new Role “developer” with the following permissions:
      • Cluster Level Permissions:
        • Prod cluster → Read-Only
        • Staging cluster → Read-Only
        • Dev cluster → Create Environment (they can create environments on this cluster)
      • Project Level Permissions for the project "P1":
        • Environment access (by env type)
          • prod = Read-Only
          • staging = deploye (i.e. they can deploy env of type “staging”)
          • development = Full Access (i.e. they can manage and create env of type “dev”)

Example 2, advanced setup: An organization with 4 dev clusters (“prod cluster”, “staging clyster”, 2 Dev clusters called “dev cluster team 1” and "dev cluster team 2”) and 2 projects P1 and P2. The organization has a CTO, a devops, 2 dev teams with an “acting dev-ops” in it who manages the dev cluster on behalf of the devops. The roles & permissions could be configured in this way:

  • CTO = Owner
  • Devops = Devops or Admin
  • Dev team 1: we want these users capable of accessing the project P1, having no access to the prod env and managing their deployments only on the "dev cluster Dev team 1" for their development environments.So the config will look like:
    • Create a new Role “Dev Team 1”
      • Cluster Level Permissions:
        • Prod cluster → Read-Only
        • Staging cluster → Read-Only
        • Dev cluster team 1 → Create Environment (they can create envs only on their dev cluster)
        • Dev cluster team 2 → Read-Only
      • Project Level Permissions:
        • Config on the project “P1”
          • Environment access (by env type)
            • prod = no-access
            • staging = deploy
            • dev = Full Access (i.e. they can do whatever they want on env of type “dev”)
        • Config on the project “P2” (i.e. they can't access P2)
          • Environment access (by env type)
            • prod = no-access
            • staging = no-access
            • dev = no-access
  • Dev team 2: we want these users capable of accessing the project P2, having no access to the prod env and managing their deployments only on the "dev cluster team 2" for their development environments. So the config will look like:
    • Create a new Role “Dev Team 2”
      • Cluster Level Permissions:
        • Prod cluster → Read-Only
        • Staging cluster → Read-Only
        • Dev cluster team 1 → Read-Only
        • Dev cluster team 2 → Create Environment (they can create envs only on their dev cluster)
      • Project Level Permissions:
        • Config on the project “P1” (i.e. they can't access P1)
          • Environment access (by env type)
            • prod = no-access
            • staging = no-access
            • dev = no-access
        • Config on the project “P2”
          • Environment access (by env type)
            • prod = no-access
            • staging = deploy
            • dev = Full Access (i.e. they can do whatever they want on env of type “dev”)
  • Acting DevOps user: we want this user capable of accessing the project, having read access to the prod env, managing the dev clusters and all the environments on it. So the config will look like this:
    • Create a new Group “Acting DevOps”
      • Cluster Level Permissions:
        • Prod cluster → Read-Only
        • Staging cluster → Create Environment
        • Dev1 cluster → Full Access
        • Dev2 cluster → Full Access
      • Project permissions settings
        • Config on the project “P1”
          • Admin (i.e.: full access to the project)
        • Config on the project “P2”
          • Admin (i.e.: full access to the project)

Change an Organization

As a user, you can have access to one or many organizations. Use the dropdown in the top right navbar to change your organization.

Qovery - change organization

Delete an Organization

To delete your organization, you need to go into the Danger Zone within your organization settings.

Qovery - delete organization

Managing Git Permissions Using the Qovery Github App

When you first sign into the Qovery Console, you need to provide your Git provider account credentials. This allows you to later take advantage of a Single Sign-On process through your Git provider. However, by default, Qovery is then allowed to access all the resources stored on your Git provider account.

For better control, as a Github user, you can install the Qovery Github App, and define which Github repositories Qovery can access.

Installing the Qovery Github App

To install the Qovery Github App:

  1. Open your Qovery Console and access your organization settings:

    How to access your organization settings

    test

  2. In the Organization settings menu, click Git Permission:

    Application

  3. Below your Git provider account click Install Github Application to manage permission:

    Application

    A new window opens in your browser so you can install the Qovery Github App on your Github account.

  4. Click the Github account on which you want to install the Qovery Github App:

    Application

  5. Click Only select repositories and, in the dropdown menu, define which Github repositories you want to give Qovery access to:

    Application

  6. To confirm, click Install & Authorize:

    Application

    You are redirected to your Qovery Console, where the list of authorized Github repositories is updated.

Managing the Github permissions

To add or remove access to one of your repositories:

  1. Open your Qovery Console and access your organization settings:

    Qovery - delete organization

  2. In the Organization settings menu, click Git Permission:

    Application

  3. Next to your Git provider account, click Manage permission:

    Application

  4. Click the Github account on which you want to manage the Qovery Github App access:

    Application

  5. Add or remove the repositories you want to give Qovery access to:

    Application

Uninstalling the Qovery Github App

To uninstall the Qovery Github App:

  1. Open your Qovery Console and access your organization settings:

    Qovery - delete organization

  2. In the Organization settings menu, click Git Permission:

    Application

  3. Next to your Git provider account, click Disconnect:

    Application

    The list of authorized Github repositories is updated, meaning Qovery now has access to all of your Github repositories again.

  4. From your browser, access your Github account and open your Settings:

    Application

  5. In the navigation menu, click Applications:

    Application

  6. At the bottom of the page, click Uninstall:

    Application

    A confirmation pop-up window opens.

  7. Click OK:

    The Qovery Github App is uninstalled.

Billing

Container Registry management

This section allows you to define the list of container registries that can be used within your organization. Only images stored on those container registries are allowed to be deployed on your cluster.

You can access this section by opening the Organization Settings -> Container Registries

Application

Create a Container Registry

Application

By clicking on "Add Registry" you will be able to create a new Container Registry by filling these information:

  • Registry Name
  • Description
  • Registry Url: the base url of the registry (example: https://docker.io, https://public.ecr.aws etc..)
  • Registry type: you can chose among DockerHub, Public ECR, ECR (AWS private CR), Scaleway CR (Scaleway private CR)
  • Credentials: these depends on the chosen registry type. If a container registry is public, you don't need to fill this part.

Modify or Delete an existing registry

You can modify an existing container registry by clicking on the "Wheel" button next to it You can delete an existing container registry by clicking on the "Trash" button next to it

Application