Can you only make a preset with shadcn/create ?

[jkinley]

Presets could be really useful for a company that wants to make a multi-architype design system. So say you have Marketing sites with more whitespace, fancy fonts, and high-ratio typescale. On the otherhand, you have web apps that are more ui dense and smaller ratio typescale.

With presets you could have both options while still sharing the same components and themes. I wonder if anyone else has thought of this. It would be cool to have one custom registry power multiple presets that are easily installed with the shad command line. Does anyone know if it is possible to tap into presets power without using shadcn/create?

[jkinley]

The more I looked into it, this does not really seem possible. I like that shadcn has added shadcn/create but this seems to be going the opposite direction of using it to build your own registry. Now it even comes with node modules installed, so not really what it used to be. I hope moving forward shadcn gets back to making features for devs that are making there own registries.

[SagarFieldElevate]

You can create presets without shadcn/create by manually structuring a custom registry. The key is setting up a registry.json that follows shadcn's registry schema, then pointing the CLI to your custom registry URL.

Here's the approach:

1. Create a JSON file following the registry schema format
2. Host it anywhere (even a GitHub raw URL works)
3. Use npx shadcn@latest add --registry https://your-url/registry.json

For multiple presets (marketing vs. dense app UI), you'd create separate style CSS files in your registry, each mapping the cn-* classes to different Tailwind utilities. Then consumers pick which preset/style to use during init.

It's more manual setup than shadcn/create, but it gives you full control over hosting your own registry with multiple presets from a single source.

[jkinley]

This makes some sense to me. However previously I thought the styles (Vega, Nova, Luma) were applied to the base components using @apply. This was cool bc you can have the same components but with spacing and radius variations, etc. From what I can tell now, since v4 the styles are not being applied via @apply.

What I have been able to do is use registry:base to make the installable design system. This is so cool.

{
  "$schema": "https://ui.shadcn.com/schema/registry-item.json",
  "name": "custom-base",
  "type": "registry:base",
  "config": {
    "style": "custom-base",
    "iconLibrary": "lucide",
    "tailwind": {
      "baseColor": "neutral"
    }
  },

However the command to install this is actually:

npx shadcn@latest init http://your-domain/r/your-registry.json

As far as I can tell this is not documented. But it works. I will keep experimenting and giving feedback here. Thanks for the input!

[jkinley]

So I transfered all the settings of a preset from shadcn/create and turned them into a registry:base item, which is cool. But based on the command above:

npx shadcn@latest init http://your-domain/r/your-registry.json

Its not going to allow for more than one registry:base item per registry. Or does it? Lots of trial and error to figure this stuff out. Anyone have any ideas? Does someone know if there is support for more than one registry:base per registry?

[jkinley]

I was mistaken. the actual command is this:

npx shadcn@latest init http://your-domain/r/the-name-of-your-registry:base-item.json

So if you name it like this:

    {
      "$schema": "https://ui.shadcn.com/schema/registry-item.json",
      "name": "shad-buddy-green",
      "type": "registry:base",

npx shadcn@latest init http://shadbuddy.com/r/shad-buddy-green.json

The good thing is that is far is that this works! You can make custom presets for you design system!

Hope this helps

[jkinley]

[jkinley]

So the good news is that I figured out how to create presets from registry:base. The bad news; it is not really useful. My idea was that I would be able to have our custom registry easily be adjusted for different web archetypes. Think compact style (Lyra) for web apps and a loose style (Luma) for a marketing page. This would be awesome bc you could use the same components and color tokens for your overall design system, but have more flexibility with where and how they are used.

To be clear, you could still do this, but you would have to maintain multiple versions of all your components...so really you may as well just create a different registry. Why? Because every time you use apply or switch to a different preset, all off the components get rewritten with new classes. So any customizations you added to your registry get wiped out, including—and this one is a head scratcher to me—any custom variants you made with CVA. This means components like buttons, badges, alerts—anything dependent on variants—all have to be manually updated every time you change a preset.

Shadcn was built on the idea that you used it to create your own component library. But with these latest features, it seems to be shifting away from that and more toward pre-configured "Wordpress" or "Bootstrap" themes and more to be used as a one-off consumer project. It's a bit of a shame this is the direction its going. I was really hoping to use presets with our custom registry.

[morganfeeney]

You could create a custom registry that contains components with generic classes, e.g. cn-heading, cn-card-title etc. and use CSS as the mechanism to provide differentiation.

[shashank-sn]

You've already discovered the key pieces yourself (registry:base, the init command pointing to a custom URL), so I'll focus on the question you're still stuck on: can one registry support multiple presets without duplicating components?

The short answer is yes, but the approach you need is slightly different from what you've been trying.

The core issue you hit

When you switch presets, shadcn init --overwrite rewrites all component files with the new style's inlined classes. That wipes CVA variant overrides, custom styling, and any other modifications you made. This is by design — presets transform the raw cn-* base components into style-specific components using transform-style-map.ts. Each preset produces a different set of component files.

The pattern that works: one base, multiple CSS layers

Instead of using presets to swap component files, keep a single set of components (installed with one style) and use CSS layers to provide the visual differentiation:

── components/
   └── ui/
       ├── button.tsx          # one version, shared by all projects
       └── card.tsx
── styles/
   ├── marketing.css           # loose spacing, larger type, fancy fonts
   └── webapp.css              # dense spacing, compact type, smaller scale

Your registry serves one set of components. Consumer projects pull those components, then apply the appropriate CSS layer override on top.

/* In the consumer's globals.css */

/* For marketing projects */
@import "./styles/marketing.css";

/* For web app projects */
@import "./styles/webapp.css";

The CSS layer overrides target [data-slot="button"], [data-slot="card"], etc. from outside the component. This works because shadcn v4 components set semantic data-slot attributes on every element.

Why this beats multiple presets

• One registry to maintain, not N
• No component duplication
• CVA variants stay intact (they're in the component, not the preset)
• Upstream updates via shadcn add --overwrite don't wipe design system customizations
• Marketing and webapp projects share the same component contract

The registry:base approach you found

Your discovery that npx shadcn@latest init http://your-domain/r/shad-buddy-green.json works is correct — a registry:base item can define the Tailwind config, color tokens, and icon library. But it can't carry style-specific CSS overrides because those are component-level transformations. The base item is for project scaffolding (colors, fonts, icons), not for visual theming across archetypes.

If you really need per-archetype component files

If the visual differences are too extreme for CSS overrides alone (completely different markup structure, different component compositions), then separate registries per archetype is actually the cleaner approach:

registry-marketing/   # components with marketing styling
registry-webapp/      # components with web app styling

Both registries share the same underlying Radix + shadcn structure, but each ships its own inlined classes. This is more maintenance but gives complete freedom.

For most teams, the CSS layer override approach (shared components + per-archetype CSS) strikes the right balance between consistency and flexibility without the maintenance burden of per-preset component files.