Managing Croct config across many client Storyblok repos, croct.json5 conventions?
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
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:
- 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.
- 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.