# Share a Static Storybook Build — One Link, With Comments

Canonical: https://commareports.com/share-storybook-static
Published: 2026-08-24

> storybook-static/ is a folder your designer can't open. Drag the build into Comma for a browsable URL with anchored comments on the component that's wrong, and a revision per build.

# Share a static Storybook build

Storybook solved the component-review problem right up to the last step. The
build is a complete, browsable catalogue of your UI — and it is a folder on
a laptop. So component review happens in one of the two bad places instead:
a screenshot in a design channel, or a PR diff where the reviewer is reading
JSX and imagining pixels.

## Drop the build in

```bash
npx storybook build          # → storybook-static/
```

Drag `storybook-static/` (or a zip of it) into [the app](https://commareports.com/):

- `index.html` becomes the **report body** — the page carrying the comment
  layer.
- The manager bundle, the preview iframe, the story chunks and the static
  assets upload alongside it.
- Relative `src` and `href` references are rewritten to the uploaded assets,
  so the sidebar tree, the story iframe and the addons panel all resolve.

The result is the real Storybook at a URL, not a picture of it. Scripts run
inside a sandboxed iframe (`allow-scripts`, no `allow-same-origin`), which is
what the manager needs to boot and what the controls addon needs to work.

## From CI, so every branch has one

```bash
npx storybook build

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html storybook-static/index.html '{html: $html}')"
```

The API is JSON-only, so the supporting bundle files go up through
`POST /api/v1/reports/$REPORT_ID/assets` as base64 — one call per file, which
is worth scripting once and forgetting. For a by-hand share, the folder drop in
the app does the same work in one motion.

PATCHing one report id gives the design system a permanent address. The link
in your README never rots, and the revision history is a build-by-build record
of how the component library actually changed — which is a far better answer
to "when did the button get taller?" than git blame on a token file.

See [publishing from CI](/docs/ci) and the [API reference](/docs/api).

## Why review the build instead of the PR

A PR review of a component catches prop-drilling and naming. A review of the
rendered build catches the things that cost you design debt:

- **The state nobody built.** Loading, empty, error, 40-character label.
  Missing states are obvious in a catalogue and invisible in a diff.
- **Drift.** Three cards that were supposed to be one card.
- **The designer's actual objection**, anchored to the story it is about,
  in a thread that survives the next build. See
  [commenting on HTML](/comment-on-html).

Access is per report — private, team, domain-gated, or named reviewers — so
an unreleased design system does not need a public URL to get looked at. See
the [sharing model](/docs/sharing).

## Limits

- **Entry HTML: 5 MB.** Assets: 25 MB per file, 250 MB and 500 files total.
- **Scripts run, sandboxed:** `allow-scripts`, no `allow-same-origin`. Stories
  that fetch from your API at same-origin paths will not; point them at
  absolute URLs or mock them, which you likely already do.
- **60 requests/minute per token.**

## Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision
history.

**[Publish a Storybook build →](https://commareports.com/)**

### Related

- [Share an accessibility report](/share-accessibility-report) — the other half of component review
- [Share Sphinx docs](/share-sphinx-docs) · [Share OpenAPI docs](/share-openapi-docs)
- [Publish from CI](/docs/ci) · [Embed a report](/embed-html-report)