shadcn/ui has shipped GitHub Registries, a feature that turns any public GitHub repository into an installable registry. By dropping a single registry.json file at the root of a repo, developers can let anyone pull components, configuration, documentation, and even AI agent rules directly with the shadcn CLI — with no registry server to host and no generated JSON files to publish.
The release extends the registry system that shadcn popularized for distributing React components and removes one of its biggest points of friction. Until now, sharing a registry meant standing up a server or publishing static JSON to a hosted endpoint. With GitHub Registries, the repository itself becomes the source of truth.
Key Highlights
- Any public GitHub repository can become a registry by adding a
registry.jsonfile at its root. - Items install with a simple address format:
pnpm dlx shadcn@latest add owner/repo/item. - Registry items are not limited to React components — they can be source files, configs, docs, templates, CI workflows, MCP setups, and agent rules.
- No registry server or hosted JSON endpoint is required; the repo is the registry.
- Installs can pin to a tag, commit SHA, or branch for reproducible results.
How It Works
To publish, a maintainer adds a registry.json file to the root of a public repository. The file conforms to the shadcn registry schema and describes each shareable item: its files, target destinations inside a consumer project, and any dependencies.
On the consumer side, installation uses an owner/repo/item address. For example, pnpm dlx shadcn@latest add acme/toolkit/project-conventions fetches an item named project-conventions from the toolkit repository owned by acme. Because the address resolves against GitHub directly, there is no namespace registration step.
Reproducibility is built in. Consumers can append a Git ref to lock the install to a specific version — a release tag such as #v1.0.0, a full commit SHA, or a branch name. That makes registry consumption behave more like a versioned dependency than a one-time copy-paste.
The CLI also ships supporting commands for working with these registries: registry validate checks that a repository's registry.json is well-formed, list enumerates the items a registry exposes, search filters items by query, and a --dry-run flag previews what an install would write before touching the file system.
Beyond Components
The most consequential shift is what counts as a registry item. shadcn's registries are no longer just a delivery channel for UI components. The documentation explicitly supports distributing configuration files such as Vitest, Prettier, and TypeScript setups, alongside documentation, templates, CI/CD workflows, MCP configurations, and agent rules.
That last category lands squarely in the current moment. As teams standardize how AI coding agents behave across projects, a registry that can ship AGENTS.md-style conventions, prompt rules, and tool configurations through the same channel as components turns project scaffolding into a single installable unit. A team can package its entire house style — components, linting, test config, and agent guidance — and let any repository pull it in one command.
Impact
For the front-end ecosystem, GitHub Registries lower the barrier to maintaining a shared component library to near zero. Indie maintainers and internal platform teams alike can distribute building blocks without operating infrastructure, and consumers get versioned, auditable installs instead of opaque package tarballs.
A growing community already orbits the registry format — directories that index trusted registries, RSS-style change trackers, and dozens of third-party component libraries built on the CLI. Making the repository itself the registry removes the remaining setup tax for that community and is likely to accelerate the number of public registries.
For private code, there is a caveat: private repositories and GitHub Enterprise hosts are not supported by the GitHub address format. Teams that need authenticated distribution must continue to use namespace registries with credentials.
Background
shadcn/ui rose to prominence by rejecting the traditional npm-package model for UI kits. Instead of installing an opaque dependency, developers copy component source into their own codebase, where they own and can modify it. The registry system formalized that copy-into-your-project workflow into a distributable format, and the CLI made it scriptable.
GitHub Registries is the logical endpoint of that philosophy: if your components already live as plain files in a repository, the repository should be all you need to share them.
What's Next
Expect the registry directory to expand quickly as maintainers convert existing repositories with a single file, and watch for agent-rule and configuration registries to grow alongside component libraries. With reproducible, ref-pinned installs and support for any file type, the line between a UI registry and a general-purpose project-scaffolding tool continues to blur.
Source: shadcn/ui — GitHub Registries