> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mangrove.dino.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces and roles

> Access in Mangrove works on two levels: what someone can do to the box, and what they can do inside each workspace.

Access works on two levels. Your **account role** says what you can do to the box itself. Your **workspace role** says what you can do inside each workspace.

## Workspaces

A workspace holds projects, and through them every deployment, database, domain and variable inside. Use one per team, client or environment. People can belong to several and switch between them with the **station switcher** at the top of the sidebar, which also has an "all workspaces" view.

Every install has a **default workspace**. It can't be deleted, and new accounts join it automatically.

* **Workspaces → New workspace** creates one. Anyone signed in can do this, and the creator becomes its admin.
* **Move to workspace** on a project moves it. You need to be an admin in both workspaces.
* **Delete** on a workspace moves its projects back to the default workspace. Nothing else is deleted.

## Roles

There are two account roles:

| Role | Can |
| - | - |
| **Owner** | Everything, in every workspace, plus accounts, sessions, ports, image pruning, backups, drive storage and the full audit log |
| **Member** | Only what their workspace roles allow |

And three workspace roles:

| Role | Can |
| - | - |
| **Admin** | Everything an editor can, plus secrets, access control, domains, deletes and the workspace's members |
| **Editor** | Create projects, deploy and operate them, and run commands inside their containers |
| **Viewer** | Read |

In detail:

| | Viewer | Editor | Admin |
| - | :-: | :-: | :-: |
| See projects, deployments, logs, history, plain variables, domains, activity | ✓ | ✓ | ✓ |
| Create projects, install templates, connect a repo | | ✓ | ✓ |
| Deploy, redeploy, roll back, scale, stop, restart, cancel a build | | ✓ | ✓ |
| Create staging and PR previews, promote, verify a domain | | ✓ | ✓ |
| Turn idle sleep and self-healing on or off | | ✓ | ✓ |
| Add, edit or delete plain variables; delete any variable | | ✓ | ✓ |
| Run a command inside a container | | ✓ | ✓ |
| Set secret variables | | | ✓ |
| Change access control, add or remove domains | | | ✓ |
| Delete projects and deployments | | | ✓ |
| Manage members, delete the workspace | | | ✓ |
| Move a project in or out (admin in both workspaces) | | | ✓ |

## Workspace membership is the real boundary

Having an account does not give you every app on the box. **Workspace membership gates access to everything inside that workspace.** Add someone to a workspace and they get its projects; leave them out and they don't see it at all. Not read-only: nothing.

Owners are the exception. An owner is an admin in every workspace, whether or not they're listed as a member.

This explains two things that can look inconsistent:

* Two members on the same box can see different lists of projects.
* Two people in different workspaces can still pick the **same GitHub repositories**, because GitHub tokens belong to the install, not to a workspace or a person. Anyone signed in can list and use them when connecting a repo.

## Editor is a trusted role

> [!WARNING]
>
> Editors can run commands inside a workspace's containers, and a running container can read its own secrets. Editors can also delete or overwrite any variable, secrets included, even though only admins can set one.

"Admin only" on secrets stops casual mistakes; it doesn't keep secrets from editors. Give editor to people you'd trust with the workspace's credentials, and viewer to everyone else.

## Adding people

Mangrove sends no email, so there are no invitations. Adding someone is two steps:

1. **Admin → Team** (owners): create the account with an email, an initial password and an account role. Share the password with them yourself; they can change it in [Settings](https://docs.mangrove.dino.icu/account/profile.md#change-password). The new account joins the default workspace as an **editor**.
2. **Workspaces → Members** (workspace admins): add the account to other workspaces by its exact email, with a role. Change someone's role or remove them here too. Removing someone only takes away that workspace.

If the new person shouldn't be able to deploy in the default workspace, change their role there to viewer, or remove them from it.

Workspace admins who aren't owners can't browse the account list. They add people they already know by email.

## Removing people

**Admin → Team → delete** removes the account and signs it out everywhere. You can't delete yourself, and you can't delete the last owner, so the box always has someone who can manage it.

There's no "last admin" check on a workspace. An owner can always manage any workspace, so it can't be stranded.

## The first owner

On a fresh install nobody has an account and nobody is owner. The first account claims the instance with a single-use **setup token**, and it is always an owner. `setup.sh` reads the token and does this for you; see [Install](https://docs.mangrove.dino.icu/start/install.md#claiming-the-instance). After that, setup is closed and every other account comes from an owner.

## Good to know

* The dashboard hides buttons you can't use, but the API enforces every rule on its own.
* Asking for something in a workspace you're not in returns `404 Not Found`, exactly as if it didn't exist, so IDs in other workspaces can't be probed. Asking for something your role doesn't allow, in a workspace you are in, returns `403 Forbidden` (for example "admin role (in this workspace) required").
* Every delete, access change, membership change and deploy is recorded. See
  [Audit logs](https://docs.mangrove.dino.icu/teams/audit-logs.md).
* The [CLI](https://docs.mangrove.dino.icu/interfaces/cli.md) and [MCP agents](https://docs.mangrove.dino.icu/interfaces/mcp.md) act with the roles of the account they sign in as. Give them a dedicated account with only the role they need.

How roles are enforced: [Multi-user and roles](https://docs.mangrove.dino.icu/internals/multi-user.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.