Workspaces and roles

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: And three workspace roles: In detail:

​

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

“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. 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. 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.
• The CLI and MCP agents 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.