Manage Organizations, Users, and Permissions

Managing Members

You can use Nx Cloud organizations to manage permissions.

When you create a new organization, you are its only member/admin. You can invite other users using their emails, or using an email domain, in which case everyone under the same domain can join the organization.

You can set one of the two roles for everyone you invited:

  • Admin (can do anything with any workspace in the organization)

  • Member (can view runs and stats, but cannot make any changes to any of the workspaces)

Public Organizations

Sometimes you don't have a known list of members (for instance, for an open-source project). In this case you can change the organization's type to  "public". In a public organization, everyone (including those without an Nx Cloud account) can see and do everything an organization member can see and do.

Managing Access Tokens

The permissions and membership define whether developers can access a particular URL on They don't affect what happens when you run Nx commands locally or on CI. To manage that you need to provision access tokens. To do that, go to Workspace Options / Manage Access Tokens.

There are two types of tokens:

  • Read - stores metadata about runs and reads cached artifacts

  • Read-Write - stores metadata about runs, reads and writes cached artifacts

Setting Access Tokens

Let's see how access tokens work.

If you open your nx.json, you will see something like this:

{ "tasksRunnerOptions": { "default": { "runner": "@nrwl/nx-cloud", "options": { "accessToken": "SOMETOKEN",     "cacheableOperations": ["build", "test", "lint", "e2e"], } } }, }

If you remove the accessToken property from the configuration, the runner will run all commands as if you were not connected to Nx Cloud. This essentially turns off Nx Cloud.


You can also set the NX_CLOUD_ACCESS_TOKEN env variable, as follows:

NX_CLOUD_ACCESS_TOKEN=SOMETOKEN nx affected --target=build

If NX_CLOUD_ACCESS_TOKEN is set, it takes precedence over the accessToken property.

Small Projects

In small closed projects where folks have similar setups, it's common to have one read-write token shared by all the developers. The token is stored in `nx.json`. Every developer can write artifacts to the cache. Other developers and CI agents, can read those values.

Large Projects

For larger projects, it's common to have a read token set in nx.json and a read/write token set as an NX_CLOUD_ACCESS_TOKEN env variable in CI. Developers can benefit from the computation performed on CI but cannot affect the CI execution. It's important to make sure that the cache is set up such that postinstall scripts won't result in different artifacts associated with the same computation hash. See the section on distribution caching for more information.

Giving Every Developer an Access Token

We don't recommend issuing every developer a separate read token. It doesn't improve security.

A token is only useful in combination with the computation hash. To get the hash the developer needs to have access to the source code. If the developer can access the source code, they can always rebuild things from scratch, without using Nx Cloud.

Select an article to learn more about Nx Cloud