# Project members and roles (/iam)



## What this controls [#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](/auth/) are managed apart from project members.

<Accordions>
  <Accordion title="Under the hood: RBAC and IAM">
    `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.
  </Accordion>
</Accordions>

## Manage members [#manage-members]

Open the project's **Users** tab. It lists each member with their **Role** and **Deployment access**.

<Steps>
  <Step>
    **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.
  </Step>

  <Step>
    **Change a role**

    Pick a new role from the member's **Role** menu. The change applies immediately.
  </Step>

  <Step>
    **Remove a member**

    Select the trash icon on the member's row. They lose access to the project.
  </Step>
</Steps>

Every role change, deployment grant, and removal is permission-checked, and nobody can change their own membership.

## Project roles [#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 [#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.

<Accordions>
  <Accordion title="Under the hood: the bindings IAM stores">
    The backend stores precise IAM bindings. They keep broad project roles and deployment-editor grants separate.

```mermaid
flowchart TD
  U[Users tab change] --> B[IAM bindings]
  B -->|checked on each action| API[Crucible backend]
  B --> H[Permission-change hooks]
  H -->|both roles| A[Auth projects]
  H -->|admins| G[GCP Editor]
  H -->|admins| T[Temporal Write]
```

    * **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.
  </Accordion>
</Accordions>