4 min read

Learn how to manage organizations within Coder.

Organizations are groups that tie together users, environments, and images. All of your images and environments must be assigned to a specific organization. An end-user can only access images that are assigned to the same organization they are.

The default organization

When you first set up Coder, you'll generate the default organization. You can then assign users and their environments to that organization.

There must always be a default organization, but you can change the one set as the default once you have two or more organizations.

Organization roles

Like User roles, members of an organization can be assigned different roles. There are two roles available:

Role Description
Organization manager Grants full administrative access to the organization and the ability to manage its images and members. Can view, modify, and delete environments belonging to members of the organization.
Organization member Grants basic organization access. Can use and view images belonging to the organization. Can create new images assigned to the organization. Can only access environments within their organization.

Please note that roles are defined per organization. Therefore, assigning someone as an organization manager does not change their role in another organization.

Organization admin permissions

Create Read (all) Read (own) List Delete (all) Delete (own) Update (all) Update (own)
Dev URLs X
Environments X X X X X X
Images X X X X
Image tags X X X X
Metrics X X
Org members X X X X X
Orgs X X
Registries X X X X
System banners X
Users X X

Organization member permissions

Create Read (all) Read (own) List Delete (all) Delete (own) Update (all) Update (own)
Dev URLs X
Environments X X X X
Images X X
Image tags X X
Metrics X
Org members X
Orgs X
Registries X
System banners X
Users X


Deprecation notice: The namespaceWhitelist field has been deprecated in Coder version 1.17.

Coder's Helm chart previously included a namespaceWhitelist field that accepted a list of cluster namespaces and made them available to Coder. The workspace provider feature supersedes this field.

You will not be able to make any changes unless you are removing namespaces that no longer contain environments with Coder deployments v1.17.0 or later (if you remove namespaces from the namespaceWhitelist field, the environments in the namespaces are no longer accessible).

For older Coder deployments, you can continue using existing environments in whitelisted namespaces, though you cannot create new environments in those namespaces.

If you want to separate Coder environments by namespaces in a Kubernetes cluster, you can do so by deploying a new workspace provider to each additional namespace in the cluster. The workspace provider provisions environments to the namespace it has been deployed to, and you can control access to each workspace provider via an organization allowlist to replace the previous organization namespace behaviors.

Our docs are open source. See something wrong or unclear? Make an edit.