RBAC and Permissions

RBAC and Permissions

ManUp's access control has two tiers: your organization role and, underneath it, a project/environment role. The effective role for a given environment is resolved per-request.

Organization role (users.type)

Every user has one org-wide role: owner, admin, or viewer.

• owner / admin are implicitly admins of every project and environment in the org — no separate membership row needed.
• viewer at the org level cannot create projects and cannot manage API keys, regardless of any project/environment membership.

Project & environment role (project_members.role / environment_members.role)

For users who are not org owner/admin, access to a specific environment is resolved as:

1. If the user has an environment-level membership row for that environment, its role wins.
2. Otherwise, fall back to the user's project-level membership role for the project the environment belongs to.
3. If neither exists, the user has no access to that environment (403).

Role values: admin, member, viewer (default for new project members is member).

What each role can do

Action	Org viewer	Env/project viewer	member	admin (env/project or org owner/admin)
Read secrets in an environment	❌ (no access)	✅	✅	✅
Create / update secrets	❌	❌	✅	✅
Delete secrets	❌	❌	❌	✅
Create projects	❌	n/a	n/a	✅ (org owner/admin only)
Manage project/environment members	❌	❌	❌	✅
Manage API keys	❌	n/a	✅	✅

A viewer anywhere in the chain cannot modify secrets — "Viewers cannot modify secrets" is returned as a 403. Only a resolved admin role can delete a secret ("Only admins can delete secrets").

Organization & membership management

• Updating the organization (name/description): owner or admin only.
• Deleting the organization: owner only — admin cannot.
• Removing a member: owner or admin only. A few extra guards apply:
  • You can't remove the organization's owner — that account has to stop being owner some other way (there's currently no owner-transfer flow) or the org has to be deleted.
  • You can't remove yourself through this endpoint — use your own account settings to leave/delete your account instead.
  • You can only remove members of your own organization.

Account self-management

• Changing your own email or username requires re-entering your current password in the same request. Changing just your name doesn't.
• Deleting your own account also requires your current password.
• The organization owner cannot delete their own account — the API returns 400 with "Organization owner cannot delete their account. Please delete the organization instead." This exists so an org can never end up ownerless by accident.

Brute-force protection

/register and /login are rate-limited by IP (not by account) — 5 requests/minute for register, 10/minute for login — independent of any API key rate limits. See Production Deployment for the multi-replica caveat.

Practical implications

• To give someone read-only access to just one environment (e.g. a CI service account's human counterpart), add them as an environment member with role: viewer rather than making them an org viewer — org viewer blocks API key management entirely.
• Org owner/admin bypass all project/environment membership checks — there's no way to scope an org admin down to fewer environments today. If you need that, use separate organizations or project-level API keys instead.