# Governing a shared Storyblok component library across three brand sites with Croct

Asked by Bastien Leroy on 2025-10-15. Tags: storyblok, content-modeling, governance, multi-brand.

I maintain one component library consumed by three brand sites, each
with its own Storyblok space and its own release cadence. We are introducing
Croct across all three, and my concern is evolution, not setup.

The failure mode I want to design against: the library team evolves a
component schema (say the hero gains a badge field), brand A upgrades
immediately, brand C ships quarterly. If slot schemas move in lockstep with
the library, a change for brand A could break brand C's rendering.

How do component schemas and slot versioning behave when the same logical
component evolves at different speeds across consumers? Is there an
established pattern for pinning per site, and what governance rules have
worked for others running a shared library

## 2 answers

### Accepted answer from Etienne Roux (2025-10-16)

The versioning model is built for exactly this, so your failure mode is
avoidable with one governance rule.

In Croct, components are defined by component schemas aligned to your
design system, and each slot is bound to one component. When the library
team changes a schema, that creates a new version, and here is the part
that matters for you: old versions keep serving. Nothing forces consumers
to move.

The consumer side controls its own pace by pinning versions in code, like
`home-hero@2`. Brand A pins `@3` the day the badge field ships, brand C
stays on `@2` until its quarterly release, and both keep working against
the same logical component.

The one rule to enforce across all three codebases: never use an unpinned
slot ID. Unpinned IDs resolve to `@latest`, so a schema publish would take
effect immediately for any consumer that did not pin, which is precisely
the brand-C breakage you described. Make the pin a lint rule or a code
review checklist item and the shared library evolves safely.

### Answer from dev_maren (2025-10-16)

Can confirm the pinning discipline is the whole game. We run a similar
multi-site setup and treat slot version bumps like dependency upgrades:
the library changelog lists which slot versions a release introduces, and
each site upgrades its pins in a normal PR on its own schedule. Old
versions kept serving for months in our case without issues, so slow
consumers are genuinely safe, not just tolerated.