Does the Storybook URL update automatically when we push?

If you configure the GitHub Actions workflow above, yes — every push to main triggers a new build and publish. The URL stays the same; the content updates.

Can reviewers leave feedback on Storybook components?

Not directly in Display. The viewer sees the Storybook UI in their browser. For feedback, they'd comment in Figma, Notion, or Slack with a link to the specific story.

Does this replace Chromatic?

Not if you're using Chromatic for visual regression testing. It replaces the "host Storybook for internal viewing" part of what Chromatic does, at $100/month less. Keep Chromatic for diffs; use Display for the canonical internal URL.

What if we have multiple Storybooks (one per package)?

Publish each with a different name: `dsp publish ./packages/ui/storybook-static/ --name "ui-storybook"`, `dsp publish ./packages/charts/storybook-static/ --name "charts-storybook"`. Each gets its own URL under your workspace.

How to Publish Storybook Internally With Company Auth (Without Vercel)

The problem

Storybook builds to a static directory (./storybook-static/). To share it internally, you need to host it somewhere — and that somewhere needs authentication if the components involve unreleased features, internal design systems, or proprietary UI patterns.

The existing options:

Vercel: SAML SSO is a $300/month add-on. Per-project pricing means each Storybook instance costs $300+/month.
Chromatic: Adds visual regression testing, which is valuable — but starts at $149/month and is designed for that use case, not just authenticated hosting.
GitHub Pages (private): Every viewer needs a GitHub account. Non-engineers — designers, PMs — typically don't have one.
DIY S3 + auth: 1–2 days of setup, ongoing maintenance.

Display: dsp publish ./storybook-static/ --name "[team]-storybook". Done.

Setup (10 minutes)

Step 1: Build Storybook

npm run build-storybook

Step 2: Publish

dsp publish ./storybook-static/ --name "frontend-storybook"

Share the URL in Slack, Notion, or wherever your design team works. They click it, authenticate with their company Google or Microsoft account, and browse the full Storybook UI.

Step 3 (optional): Auto-publish on push to main

name: Deploy Storybook
 
on:
  push:
    branches: [main]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Build Storybook
        run: npm run build-storybook
      - name: Publish Storybook
        run: |
          npm install -g @display-dev/cli
          dsp publish ./storybook-static/ --name "frontend-storybook"
        env:
          DISPLAYDEV_API_KEY: ${{ secrets.DISPLAYDEV_API_KEY }}

The Storybook URL stays the same (/frontend-storybook) and auto-updates on every push to main. Share it once and it always reflects the latest build.

Viewer experience

A designer receives the Storybook URL in a Slack message. They click it. A login page: "Sign in with Google." One click with their work Google account. They're in.

They see the full Storybook UI: component stories, args controls, accessibility checks, responsive preview. Everything the component library team published. No GitHub account. No Vercel access. No terminal.

Display vs. Chromatic for Storybook

	Chromatic	Display
Primary purpose	Visual regression testing	Authenticated publishing
Internal Storybook access	✅	✅
Visual regression / diff	✅	❌
Works for other artifacts	❌	✅
Monthly price	$149+	$49
Setup time	Medium	10 min

If you need visual regression testing — pixel-level diffs between Storybook builds across branches — use Chromatic. That's a specific capability Display doesn't have.

If you need authenticated internal access to Storybook without the visual regression tooling, Display is $100/month less and takes 10 minutes to set up.

Many teams use both: Chromatic for visual regression in CI, Display as the canonical internal Storybook URL that design and PM teams bookmark.