# Sanity dataset per environment vs Croct environments, how should they line up?

Asked by emil_s on 2026-01-21. Tags: sanity, environments, setup, workflow.

We run production and staging Sanity datasets, one Next.js app deployed
twice, and we are adding Croct now.

Do people mirror this with separate Croct environments? And what actually
differs between two Croct environments in practice, slots, content, audiences,
all of it? Want environment parity without maintaining everything twice

## 2 answers

### Answer from Anouk Visser (2026-01-21)

Yes, mirror it. Croct supports multiple environments per application, and the
natural pairing is staging dataset with the dev environment, production dataset
with prod. That way test traffic and half-built experiences never show up in
production analytics.

The wiring lives in two places:

- `croct.json5` lists the applications per environment, so the CLI and builds
  pick the right one for the deployment they run in.
- Env vars differ per deployment: `NEXT_PUBLIC_CROCT_APP_ID` points at the
  environment's application, and `CROCT_API_KEY` is per environment too. Mind
  that the API key needs the "Issue user tokens" permission, server-side auth
  fails without it and the error does not scream the cause at you.

Identity storage is origin-scoped as well, so sessions on the staging domain
do not bleed into prod.

### Answer from davide_m (2026-01-22)

On the "maintaining everything twice" worry: in practice we do not keep the
two environments in perfect parity and it is fine. Dev is where developers
verify the slot mapping and the fallback wiring against the staging dataset,
with throwaway experiences. The real audiences and experiences are authored
once, in prod, by the marketing team. So the duplication is limited to the
config (app IDs, keys), not the content work. Trying to sync experiences
across environments is effort we never found a payoff for.