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 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, Give a script or agent access and Select a workspace.
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 and Sleep, wake and delete a database.
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.
For command syntax, see the generated workspace CLI reference.