A design system isn't done when it's designed, it's done when products can depend on it. Releases turn the current state of main into an immutable, versioned snapshot; distribution builds that snapshot into installable packages and token exports your products pin to. Available on Pro and Enterprise.
Immutable Releases
Cutting a release captures everything: the complete token state and the exact version of every component. Releases are immutable, nothing a version references can ever change under you, so 2.1.0 means the same thing next year as it does today. Consumers pin a version; upgrades are a choice, not a surprise.
Suggested semver
Spektral diffs against your last release and proposes the bump: removals are breaking (major), additions are features (minor), value tweaks are patches. You can always override.
Drafted changelog
Every release gets a changelog drafted from the actual diff, components added or updated, tokens changed, ready to edit before you cut.
Release-to-release diffs
Any two releases diff instantly, see exactly what changed between the version a product uses and the one it's upgrading to.
Distribution: From Release to npm install
Distribution builds a release into the artifacts your products consume. The desktop app, which already has your platform's toolchain, materialises the release, runs the real build, and produces a versioned package plus token exports. Publishing happens server-side, so registry credentials never touch a laptop.
release v2.1.0 → desktop builds: component library + tokens (CSS, JSON) → package tarball versioned 2.1.0 → published to your registry (or stored as a downloadable artifact) # in a consuming product npm install @yourteam/design-system@2.1.0
Targets & Secrets
npm registries
Publish to npm or a private registry. The token is stored encrypted on the server and injected only at publish time by a server-side job, it is never sent to the desktop app.
Artifact-only
No registry? The built package and token exports are stored as downloadable artifacts, ideal for air-gapped setups or CI that publishes internally.
Getting Started
On Pro or Enterprise, use the release control in the desktop header: review the suggested version and changelog, cut the release, and distribute it to a configured target. Configure targets (and their credentials) in the web dashboard. Review gates for what lands on main are covered in Branches & Review.