# Prod and staging

> Keep staging in its own Namespace, with an API key that can't reach prod.

URL: https://www.caprid.com/docs/guides/prod-and-staging/
Source: https://github.com/muxinc/switchboard/blob/main/docs/public/prod-and-staging.md

You usually want staging to be a copy of prod that can't touch prod. On
Switchboard, you get that with one Namespace for each, in the same
Organization: `acme` for prod and `acme-staging` for staging. Each Namespace
has its own signing keys, so a Client token signed for staging can't publish
to or watch anything in prod, even when the two share relays.

## 1. Create the staging Namespace

Your Organization already has the Namespace you signed up with. Create the
second one on the Organization's page in the dashboard, or with the API:

```bash
curl https://app.caprid.com/v1/organizations/4/namespaces \
  -H "Authorization: Bearer $SB_API_KEY" \
  -d '{"namespace": "acme-staging"}'
```

To find your Organization's id, call `GET /v1/organizations`.

## 2. Give staging its own API key

Your staging deploys and CI need an API key, and it shouldn't be one that can
read prod's signing keys. Create a key limited to staging:

```bash
curl https://app.caprid.com/v1/organizations/4/api-keys \
  -H "Authorization: Bearer $SB_API_KEY" \
  -d '{"label": "staging-ci", "namespaces": ["acme-staging"]}'
```

The response has the secret, which is shown only this once. Store it where
staging reads its config. This key:

- can create signing keys and mint Client tokens in `acme-staging`
- can't see or change anything in `acme`
- can't create API keys, enroll relays, or manage the Organization

For the details, see
[Limit an API key to some Namespaces](https://www.caprid.com/docs/guides/credentials/#limit-an-api-key-to-some-namespaces).

## 3. Point staging at its Namespace

Staging's backend should call the `/v1/namespaces/acme-staging/...` routes and
sign tokens with a staging signing key. Paths in its tokens start with
`acme-staging/`, for example `acme-staging/room/42`.

Your players and publishers don't change. They connect to the same relays,
with whatever token your backend hands them. If you run Self-hosted relays,
they already carry every Namespace in your Organization, so you don't need a
second fleet for staging.

## Delete staging when you're done

An Owner can delete `acme-staging` from its settings tab in the dashboard.
That deletes its signing keys. The API keys limited to it stop working, so
you should revoke them too.

The name `acme-staging` can never be used again. If you might want staging
back later, leave the Namespace in place.