# Auth sandboxes (/auth-sandboxes)



## Environment boundaries [#environment-boundaries]

Crucible keeps development sign-in separate from production, so teams can test freely without mixing sandbox identities into the live product. Each project has one sandbox sign-in project and one production sign-in project.

```mermaid
flowchart TD
  subgraph S[Sandbox]
    D["Local development,<br>workspaces, PR previews,<br>lite deployments"]
    FS["Full deployments<br>on Sandbox"]
    SS[Sandbox sign-in project]
  end
  subgraph P[Production]
    FP["Full deployments<br>on Prod"]
    PS[Production sign-in project]
  end
  D --> SS
  FS --> SS
  FP --> PS
```

| Boundary     | Sandbox                                                                                                          | Production                                                                              |
| ------------ | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| Purpose      | Building and testing                                                                                             | The live product                                                                        |
| Runtimes     | Local development, workspaces, PR previews, lite deployments, and full deployments whose **Auth** is **Sandbox** | Full deployments whose **Auth** is **Prod**, including the template's `prod` deployment |
| Who signs in | Your team and test users                                                                                         | Live product users                                                                      |

Choose a full deployment's **Auth** when you create it in the **New deployment** dialog; **Sandbox** is the default. A deployment's **Settings** show it as **Auth mode**.

## Automatic access [#automatic-access]

Crucible keeps project access aligned with sign-in access without routine Auth administration.

* **Project creator**: Receives sandbox and production sign-in access during project setup.
* **Project members**: Adding someone to the project, or removing them, grants or revokes their sign-in access in both environments. They need an account with the same email in that environment first.
* **Credential reuse**: When the Auth platform has user mirroring on, new production accounts are copied to sandbox with the same password, so one set of credentials works in both.

Development and production stay isolated even when the same person can sign in to both.

<Accordions>
  <Accordion title="Under the hood: identity matching">
    Sandbox and production are separate Auth instances, so the same person has a different user record in each. When project permissions change, Crucible looks up that person's Auth user by email in each environment and attaches or detaches it; if no user exists for the email, the sync skips that environment. Every sandbox runtime shares the project's sandbox sign-in project and registers its own sign-in callback URL and service API key. Workspaces, PR previews, and lite deployments take their Auth environment from `project.yaml`, where the template defaults them to sandbox.
  </Accordion>
</Accordions>