Deploying my storybook is very simple
Once your components live in Storybook you can turn it into a static site and host it anywhere, so your team, your clients or your future self can browse the component library online — always up to date. Here is the whole flow: the build command, a real story, how to deploy it, and the gotchas that actually waste your afternoon.
Why deploy it at all?
Storybook running on localhost:6006 only helps the person who ran it. Deployed, it turns into a shared surface: designers review components without cloning the repo, QA can link a bug straight to the broken state, new teammates learn the design system by clicking through it, and you get a permanent URL for every component to paste into a pull request or a design ticket. It is the cheapest living style guide you can ship — the build already exists, you are only hosting the folder it produces. The one caveat: a public Storybook exposes your internal component API, so if the library is private, put it behind auth (an access-protected preview, basic auth, or a private host) instead of a public subdomain.
1. Storybook commands
storybook build outputs a static site to storybook-static/ — that folder is what you deploy.
2. Write a story for a component
A story is a single rendered state of a component. Keep one .stories.tsx file next to each component. This is the classic API most tutorials still show:
Stories on current Storybook (CSF3)
That ComponentStory / ComponentMeta pair is the Storybook 6 API and is deprecated from Storybook 7 onward. On Storybook 8 (the current major in 2026) the format is CSF3, which drops the template boilerplate — a story is just an object with args:
If you are migrating, npx storybook@latest migrate csf-2-to-3 does most of the mechanical work. Pin the version in your post or repo so readers know which API they are looking at — this is exactly the kind of thing that rots.
3. Build the static site
npm run build-storybook # or: yarn build-storybook# → outputs the site to ./storybook-staticnpx serve storybook-static # optional: preview it locally first
Preview it locally before you deploy. If it looks wrong when served from serve (a plain static server), it will look wrong on the host too — better to find out now.
4. Deploy the storybook-static folder
Point any static host at that folder:
- Vercel: import the repo, set Build command to
npm run build-storybookand Output directory tostorybook-static. - Netlify: same build command, Publish directory
storybook-static. - GitHub Pages: publish
storybook-static/from a GitHub Action (the officialupload-pages-artifact+deploy-pages).
To rebuild on every push, the shape of the CI job is short:
That is exactly how the example below is built and served from a subdomain.
Gotchas that waste an afternoon
- Blank page or missing styles: a base-path mismatch. Host at the domain root (a subdomain works well) or set the base path; the browser console will show 404s on the bundles.
- Peer-dependency install failures: Storybook majors lag behind the newest React. On React 19 you may need
--legacy-peer-depsto install, and some addons will not have caught up — check the addon's support matrix before you upgrade, not after. - Stale build: hosts cache aggressively. If your changes do not show, confirm the deploy actually rebuilt
storybook-staticand bust the CDN cache.
Here is mine deployed on a subdomain: https://storybook.xabierlameiro.com
