Sanity dataset per environment vs Croct environments, how should they line up?
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
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.
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.