Project members and roles
Give each person the access they need without turning every project into a custom permission system.
What this controls
Project roles control who can operate a Crucible project: change settings, manage deployments, create workspaces. Add a person, give them a role, and Crucible enforces it on every action.
This governs the Crucible project itself. What end users can do inside the product you built is separate; your product owns its own roles, and its sign-in users are managed apart from project members.
RBAC (Role-Based Access Control) is the role you give a member: Project Admin or Project Basic Access. IAM (Identity and Access Management) is the lower layer you do not normally touch: member changes write IAM bindings, and the backend checks them before allowing project, deployment, auth, env-var, workspace, or settings actions.
Manage members
Open the project's Users tab. It lists each member with their Role and Deployment access.
Add a member
Select Add member, enter the person's Email, choose a Role, then select Add. Crucible creates or reuses the user and grants the role on this project.
Change a role
Pick a new role from the member's Role menu. The change applies immediately.
Remove a member
Select the trash icon on the member's row. They lose access to the project.
Every role change, deployment grant, and removal is permission-checked, and nobody can change their own membership.
Project roles
- Project Admin: For operators. Manage members, settings, and integrations; choose the production deployment; edit every deployment; create workspaces and lite and full deployments; manage sign-in users in sandbox and production; operate the project's provisioned cloud resources and workflows once access propagates.
- Project Basic Access: The safer default. View the project, create workspaces and lite deployments, view sign-in users and invites, and edit only the deployments you grant.
Deployment access
The project role sets the baseline, and per-deployment grants refine it. Make a Basic Access member an editor on exactly the deployments they operate.
| Criteria | Project Admin | Project Basic Access |
|---|---|---|
| Default | Edit on every deployment, from the role itself. | View on every deployment. |
| Grant Edit | Not needed; there is no per-deployment grant to manage. | Set a deployment to Edit when that person should operate it. |
| PR previews | Edit, like every other deployment. | Grouped together and use the same View and Edit controls. |
Edit lets a member change variables, redeploy, delete, and open the deployment's Terminal. The Deployment access column in Users shows All or how many deployments a member can edit. To set a deployment to View or Edit, expand the member's row under Developer Access in the classic Crucible UI.
The backend stores precise IAM bindings. They keep broad project roles and deployment-editor grants separate.
- Project binding: Adding a member creates a project-level binding tagged as managed by project settings. Admin permissions also grant Editor on provisioned GCP projects and Write on Temporal Cloud namespaces through asynchronous permission hooks. Basic Access does not grant these provider roles. Removing the last qualifying admin grant revokes the direct Editor or Write membership while preserving higher and unrelated access. Provider failures are logged and require a later permission change or manual repair.
- Sign-in access: Both roles grant access to the project's sandbox and production auth projects. A permission-change hook syncs that membership to Auth.
- Deployment editor binding: Setting a deployment to Edit creates an environment full-access binding scoped to that deployment.
- Permission checks: Member routes require project-member permissions before they list members, change roles, add editors, or remove access.