Roles & permissions

OrcheStack ships with three system roles — Admin, Engineer, Analyst — and lets Admins create additional roles with fine-grained per-service permissions.

The role model

Every user has exactly one role. A role is a named bundle of permissions. Permissions are defined per service — the same role can have different capabilities on different services.

Permission matrix

For each (role, service) pair, four permissions apply:

• can_start — may initiate service spin-up (cold tier only)
• can_use — may access the service's UI while it's running
• can_force_stop — may kill the container even when other users have active sessions (emergency)
• can_edit_config — may modify the service's credentials / env vars

System roles

Creating custom roles

From the OrcheStack admin dashboard, go to Users → Roles → New role. For each service, tick the permissions you want. Save.

Example — an "Analytics Engineer" role that can operate dbt and pgAdmin but has read-only access to Metabase:

service     | can_start | can_use | can_force_stop | can_edit_config
dbt         | ✓         | ✓       |                | ✓
pgadmin     | ✓         | ✓       |                |
postgres    |           | ✓       |                |
metabase    |           | ✓       |                |
airbyte     | ✓         | ✓       |                | ✓

How enforcement works

Every protected dashboard page has a guard at the top that checks the current user's role permission against the service they are trying to interact with. Unauthorised attempts redirect to the dashboard with a friendly error message.

Below the application layer, PostgreSQL role-level privileges provide defence-in-depth: an Analyst role in PostgreSQL lacks CREATE and DROP privileges on the marts schema, so even a compromised dashboard process cannot elevate their access.