Release & registry

A released design system is a versioned package, not copy-pasted code. You release from Milda; consumers install from a registry with npm install - just like any dependency.

#Release assembly

Releasing turns the generated output into installable packages. The release layer takes your design system - components plus theme - and produces a release plan: the set of packages and their package.json manifests. The assembly is pure and side-effect-free; a build service consumes the plan to build and publish.

• Granularity is a choice - one package for the whole system, or per-component packages plus a shared theme.
• Versioned - the version is computed from the contract diff against the previous release, and every release stores the document it was built from, immutably, so the past stays reproducible.

#What ships beside the code

A released package is read by two audiences, and only one of them can open the editor. So a release can also write the design system out in a form that is readable without running anything - generated from the same IR, on every release, so it cannot drift from what you published. Each file is opt-in per project, in Settings → Publishing, and can be changed for a single release from the release dialog.

• DESIGN.md - every token, component, prop, event and slot as readable markdown.
• AGENTS.md - how to build with this library: what the API is, what is closed, and what not to do. The rules a coding agent needs before it writes a line.
• llms.txt - the conventional index an AI tool looks for first, pointing at the files this release actually wrote.
• design-system.json - the same contract as data, for scripts and tools rather than readers.
• design-system.milda - the design system in its own authoring language, shipped with the package.

These are the offline half of the MCP server: the same contract, without a connection or an account. A package that vendors third-party icon artwork also carries a NOTICE.md naming exactly the sets it used. The consumer's view of all of this is on Using a generated library.

#The registry

Packages publish to a registry that speaks the npm protocol: the hosted Milda registry, npm, GitHub Packages, or any registry of your own. A release can also publish from the consuming organisation's own GitHub Actions through the Milda GitHub App, so the credentials never leave their account.

Consumers route only your scope to the private registry and leave everything else on the public npm registry - no mirroring, no risk to your other dependencies:

# .npmrc
@your-scope:registry=https://registry.your-company.com
# all other packages continue to resolve from npmjs

#“No eject” - and you still own the code

Two things that sound contradictory are both true:

• You own the output. Export is always available; the generated code is yours, unrestricted. That's the trust pillar.
• You don't need to eject. Because the release pipeline - versioned packages, npm install, live updates - is seamless, ejecting is an escape hatch you rarely reach for, not a routine step.

For the broader open/paid split, see Editions & pricing.