# Workspace permissions

> What admin, editor and viewer roles allow, and how membership affects access

> Nevia is in beta and open to selected teams. Public launch in Dec 2026. The CLI installs with `curl -fsSL https://get.nevia.cloud | sh`, and the MCP server is at https://api.nevia.cloud/mcp. A person signs in once in the browser.
> Setup, sign-in and requesting access: [SKILL.md](https://nevia.cloud/SKILL.md). When Nevia fits and when it doesn't: [why.md](https://nevia.cloud/why.md).

> For the complete documentation index, see [llms.txt](https://nevia.cloud/llms.txt). This page's HTML version: https://nevia.cloud/docs/reference/workspace-permissions

Each member has one role per workspace: `admin`, `editor` or `viewer`.
That role grants access to the workspace and its computers and databases.
The same user can hold different roles in different workspaces. A
[principal that signs in with a private key](https://nevia.cloud/docs/workspaces/private-key-auth.md) is a member too, with `editor` or
`viewer`; it is never an admin and cannot create workspaces.

For the procedures, see [Create a workspace and manage access](https://nevia.cloud/docs/workspaces/manage.md),
[Give a script or agent access](https://nevia.cloud/docs/workspaces/private-key-auth.md)
and [Select a workspace](https://nevia.cloud/docs/workspaces/select.md).

## Permissions by role

This table shows access granted by the workspace role. Direct resource grants
can add access, as described below.

| Action                                                                     | Admin | Editor | Viewer |
| -------------------------------------------------------------------------- | ----- | ------ | ------ |
| View the workspace and list its members                                    | Yes   | Yes    | Yes    |
| List and inspect computers, databases, computer checkpoints and operations | Yes   | Yes    | Yes    |
| Read computer logs                                                         | Yes   | Yes    | Yes    |
| List secrets and variables, and read variable values                       | Yes   | Yes    | Yes    |
| Create, replace or delete secrets and variables                            | Yes   | Yes    | No     |
| Create computers and databases                                             | Yes   | Yes    | No     |
| Change settings, branch, sleep or wake computers and databases             | Yes   | Yes    | No     |
| Run commands on computers                                                  | Yes   | Yes    | No     |
| Retrieve database connection details, including passwords                  | Yes   | Yes    | No     |
| Create, restore or delete computer checkpoints                             | Yes   | Yes    | No     |
| Delete computers and databases                                             | Yes   | Yes    | No     |
| List secrets and variables, read variable values (never secret values)     | Yes   | Yes    | Yes    |
| Create, replace or delete secrets and variables                            | Yes   | Yes    | No     |
| Reference variables in a computer's env                                    | Yes   | Yes    | Yes    |
| Reference secrets in a computer's env                                      | Yes   | Yes    | No     |
| Open an interactive session whose env references secrets                   | Yes   | Yes    | No     |
| Open an interactive session whose env references only variables            | Yes   | Yes    | Yes    |
| Rename or delete the workspace                                             | Yes   | No     | No     |
| Add members, change roles or remove members                                | Yes   | No     | No     |

Permissions do not bypass resource constraints such as deletion protection or
checkpoints in use by another computer. See [Computer lifecycle states](https://nevia.cloud/docs/reference/computer-lifecycle.md)
and [Sleep, wake and delete a database](https://nevia.cloud/docs/databases/lifecycle.md).

## Creating a workspace

Any signed-in user can create a workspace and becomes its admin. Creation does
not require an admin role in another workspace. An editor or viewer in one
workspace can create and administer a separate workspace.

Choosing a workspace in the CLI changes the command's context. It does not
grant membership or change a role.

## Membership constraints

* The person you add must already exist in Nevia. Signing in registers them;
  use the email or principal ID shown by their `nevia whoami`.
* Adding someone who is already a member fails. Change their existing role instead.
* The API refuses to demote or remove the last admin. Make another member an
  admin first.
* Removing membership removes access inherited from that workspace role.
  It does not remove the person's account or their other memberships.
* A workspace must have no live computers or databases before an admin can
  delete it.

## Direct resource grants

The authorization model also supports direct `viewer` and `editor` grants on
individual computers and databases. A direct viewer grant adds view access;
a direct editor grant adds view and edit access.

Neither grant provides workspace membership, workspace-wide listing, member
management or resource deletion. Deleting a computer or database requires the
workspace admin or editor role.

Removing workspace membership leaves direct resource grants in place. Creating
a computer or database gives its creator no extra owner permissions.
The current CLI and public API do not expose grant management.

A session needs edit on the computer as well. Secret references anywhere in the
merged env, stored or from `-e`, require the workspace `editor` role; variable-only
needs any workspace role. A direct grant on just the computer cannot reach workspace
secrets.

For secrets and variables, see [Give computers secrets and variables](https://nevia.cloud/docs/workspaces/secrets-and-variables.md).

For command syntax, see the generated
[workspace CLI reference](https://nevia.cloud/docs/reference/cli/workspace.md).