Export & own your code

Milda's first promise is that the code is yours. What comes out of the compiler is plain React and TypeScript - no proprietary runtime, no hidden dependency on Milda at your app's runtime. This page is the concrete version of that promise: what “you own the code” actually means, the real ways to get and keep your code today, and what happens if you ever walk away.

#What “you own the code” means

Milda is a compiler, not a component runtime you rent. The React generator turns your IR into ordinary source files - one .tsx per component, a shared theme.css of design tokens, and a self-contained Icon module. Concretely:

No proprietary runtime. The generated components import only react and react-dom (declared as peer dependencies). There is no @mildastudio/runtime your app has to pull in to render them - the output stands on its own.
No hidden calls home.Assets like custom icons and fonts are vendored into the output as inline data at release time, so a running app never hotlinks Milda's storage. Nothing about the shipped code phones back to us.
Ordinary React you can read and change.The code is generated to be idiomatic - the same source the example design system's storefront imports directly. You can vendor it into your repo and edit it like any other file.
The output is legally yours.Per Milda's output-ownership clause, the generated code is your code, unrestricted, and is not treated as a derivative work of the generator. That clause is non-negotiable regardless of which edition you're on. See Editions & pricing.

Escape hatch, not edit-the-output

Owning the code doesn't mean hand-patching generated files as a routine workflow - that fights the compiler. Extensibility is designed into the IR (slots, asChild, declared seams) so you rarely need to. Ejecting is the escape hatch that's always there; it's not the daily path.

#The real ways to get your code today

There are two routes to holding your code, and they serve different needs. Both exist and work now.

#1. Install the released library

The primary, supported path. You release your design system from the Studio; the registry service builds it and publishes a versioned npm package. Consumers install it like any dependency:

bash

npm install @your-scope/ds

The published package is a normal, built npm artifact: ES modules, CommonJS, and .d.ts type declarations (built with tsup), plus the raw theme.css. It depends only on React as a peer. Because it's a plain package on the npm protocol, once it's in your node_modules (or your lockfile / an internal mirror) it behaves like any other dependency you control - no Milda account is needed to installit or to keep using a version you've already got.

Published = built, not source

The published package ships compiled dist output (esm + cjs + types), not the readable .tsxsource. That's the right shape for consuming a library. If what you want is the editable source itself, use route 2.

#2. Generate the source locally

The generator is the open part of Milda. Given a design system's IR, it emits the actual source files - the same generate()the release pipeline runs, just written to disk instead of built and published. This is the mechanism behind the “local generation” that's free forever in the open client, and it's how you get real, editable React to vendor into your own repository.

In the monorepo, the example design system demonstrates exactly this: a generation script walks the components, calls the generator per component, and writes each .tsx, the shared Icon.tsx, theme.css, and a barrel index.ts to an output directory that the storefront app then imports directly. The output is byte-identical to what the release publishes - the difference is source on disk versus a built package.

The generator packages (@mildastudio/generate, @mildastudio/core) are the open-core foundation - see Generators and Packages.
Because generation is deterministic from the IR, you can regenerate at will and diff the output - nothing is locked inside a service.

No one-click “Export source” button yet

The Studio does not currently have a single “download my source as a zip” button. An earlier copy-paste-per-component export was replaced by the release pipeline, which is the supported way to ship. Local source generation exists through the open generator packages (route 2), but a first-class one-click “eject to source” action in the editor is on the roadmap, not shipped. We'd rather say that plainly than imply a button that isn't there. The one download action in the editor today is the Figma target (design tokens as Variables JSON / DTCG) - not React code.

#What happens if you stop paying or leave

The freedom to leave is the whole point of the ownership promise, so here it is concretely. The line runs between the code you already have and the hosted pipeline that produces new code.

#What you keep

Every version you've already installed. Packages already in your lockfile, node_modules, or an internal npm mirror keep working. They don't check a license at runtime and don't need Milda to be reachable.
Any source you've generated or vendored. Source produced via the open generator (route 2) or checked into your repo is yours to keep and edit forever. Nothing revokes it.
The open generator itself. Local generation, the core, and the DSL are the open client. You can keep generating a React library from an IR you hold, on your own machine, with no subscription.

#What you lose

Private registry hosting. The hosted, versioned @scope/dsregistry is the paid gate. Without it you don't get new hosted publishes - but you can point the same protocol-compatible flow at your own registry or publish to the public npm registry, and Enterprise supports bring-your-own / self-hosted registries.
New releases through the hosted pipeline.Cutting new versions via the Studio's release flow (build + publish + contract-diff versioning) runs on the hosted service. Stop paying and you stop getting new versions from that pipeline - not the ability to generate code, which stays open.
The editor and collaboration. The visual Studio, real-time collaboration, roles, and version history are the hosted product. What they produce (your IR and your generated code) is portable; the convenience of authoring in the Studio is what the subscription buys.

“No eject” reconciled

You'll see Milda described as “no eject.” That is not a cage. Eject is always available - the code is yours. “No eject” means you rarely need to, because the hosted pipeline (versioned packages, npm install, live updates) is seamless. The pipeline's convenience is the paid value; the freedom to leave with your code is the trust.

#In short

The output is plain React/TS you legally own - no proprietary runtime, no calls home.
Get it two ways today: npm install the released package (built), or generate the editable source locally with the open generator.
If you leave, you keep everything already installed or generated and the open generator itself; you lose the hosted extras - private registry hosting, new hosted releases, and the editor.
A one-click “eject to source” button in the Studio is roadmap, not shipped.