# Managing Croct config across many client Storyblok repos, croct.json5 conventions?

Asked by priti_s on 2026-01-20. Tags: storyblok, agency, cli, workflow.

Our agency now runs the Storyblok integration for four clients and every repo
has a croct.json5 that drifted in its own direction. One pins slot versions,
one doesn't, two structure environments differently.

Before client five lands I want a convention. How do others structure
organization, workspace, and per-environment applications so onboarding a new
client is repeatable? any conventions you wish you had adopted earlier

## 1 answer

### Answer from Marcus Webb (2026-01-21)

We standardized this across client repos last year, here is what stuck.

One workspace per client, and the croct.json5 in each repo pins the full
chain: `organization`, `workspace`, and `applications` per environment
(dev and prod), plus `defaultLocale` and `locales`. Making every repo carry
the same shape is what makes onboarding repeatable, our template repo has a
croct.json5 skeleton and a new client is a matter of filling in the IDs.

Two conventions I wish we had adopted from day one:

1. Always pin slot and component versions explicitly. The specifiers support
   exact (`"3"`), range (`"1 - 3"`), and set (`"1, 4, 5"`) forms. We use
   exact pins in client repos so a content-side publish never surprises a
   production build.
2. Commit the generated `slots.d.ts`. The CLI generates it, and committing
   it means builds do not need an API fetch at build time, which also keeps
   CI working when a client rotates credentials without telling you.

Drift stops being a problem once the file is part of the project template
rather than something each dev writes from memory.