21st Registry

Publish & manage on the 21st registry

Publish components, themes and templates to 21st.dev, and manage what you've already published, all through the unified 21st CLI (@21st-dev/cli).

Pre-flight (always)

1. Authenticate before publishing. Component publishing, inventory, checkout, metadata editing, and unpublishing accept either a 21st login session or a 21st_sk_… API key. Theme/template commands still require a real API key from https://21st.dev/settings/api-keys, passed via --api-key, TWENTYFIRST_TOKEN, or API_KEY_21ST.
2. The CLI is the unified @21st-dev/cli (bin 21st). Don't reinvent — use it.
3. Search before publishing (21st search "<query>") so you don't add a duplicate to the library.

Find existing components and drafts

Start here when the user asks to continue or edit old component work:

21st components
21st components --status draft --scope personal --json
21st open component:123
21st open draft:<uuid> --no-open

21st components drains both independently paginated collections by default, so an unfiltered run returns every accessible personal or Team component and every owned draft. Narrow it with --status all|draft|published|private or --scope all|personal|team:<uuid>. Keep the returned stable component:<id> or draft:<uuid> reference; do not substitute a slug.

21st open draft:<uuid> resumes an editable Studio draft. 21st open component:<id> creates or resumes a server-owned CLI Review revision from the retained published component code and demos. The live component stays unchanged until that revision is published. Fresh covers are required, while optional video generation runs best-effort in the background. --no-open creates or resumes the workspace and prints its URL without launching a browser.

Use a local file when the source is already changed:

21st publish ./Component.tsx \
  --component component:123 \
  --description "What changed"

Never replace the stable ref with a same-slug guess. Only the original component author can check out code. A Team manager can still edit or unpublish a teammate's component metadata by stable ref.

Checkout fails closed when retained source, dependencies, style, support files, or the default demo cannot be reproduced safely. Use the local source command above instead of weakening the checks or claiming code access.

A login session can inventory personal work and Teams the user can manage. A personal key is personal-only, while a Team key is restricted to that Team. New CLI Review drafts persist their authenticated personal or Team/library scope. Legacy proof-backed CLI drafts are recovered into the matching authenticated scope. An older unsigned draft whose scope cannot be proven may need to be recreated.

Publish a component

The positional file path triggers auto-detection — name from the exported component, slug from the filename, tags from imports, and a demo that is auto-found or synthesised. For a new slug or an owned revision, the command validates dependencies, installs and builds the component, creates a Studio draft, opens its dedicated CLI Review, and waits. The review sidebar shows the exact Demos (N) count and keeps the selected demo beside its live preview. Studio generates the required cover first, then attempts an optional video in the background. An owned revision stays pending until it completes the same CLI Review and is published.

21st publish ./path/to/Component.tsx \
  --to default \
  --description "1-2 sentences: what it does and when to use it"

Decide access — default to Published

Publishing controls access only. Catalog featuring is always a separate review action, so publishing never silently submits the component.

Flag reference

For a new slug or owned revision, the command prints the Studio draft URL and reports the component URL and install line only after Studio publishes it. Pressing <kbd>Ctrl</kbd>+<kbd>C</kbd> stops the CLI from waiting but keeps the draft.

Give the demo live controls (a knobs panel visitors can play with)

There is no flag for this: controls come from the demo's own code. Declare one module-level settings object and let the default export take props, and the publish pipeline derives a live panel next to the preview. Visitors move the knobs and "Copy code" hands them the code with their values written back into the settings literal, so a configurable demo is worth far more than a static one. Do this for anything with tunable values — particle counts, speeds, colors, sizes, labels, feature flags.

const settings = {
  particleCount: 1000,
  speed: 0.4,
  showGrid: true,
  glowColor: "#7dd3fc",
  palette: ["#0ea5e9", "#f472b6"],
  headline: "Ship faster",
}

export default function Demo(props: Partial<typeof settings>) {
  const s = { ...settings, ...props }
  return <Hero count={s.particleCount} speed={s.speed} ... />
}

Both halves are required. Settings without props (or props without settings) gets no panel, because knobs that move nothing are worse than none.

What each value becomes, with labels and ranges guessed from the value itself (particleCount -> "Particle Count"):