# BagUi: a shadcn/ui registry for blocks, sections and animated components

> BagUi is an MIT-licensed shadcn/ui registry of navbars, heroes, footers, pricing tables and CTAs built with Next.js, TypeScript, Tailwind CSS and Motion. This review covers how the registry mechanism works, how to run the site locally, and where the documentation stops short.

**anelkabag/bag-ui** — BagUI is an open-source shadcn/ui registry with production-ready components, blocks, templates, and animations for React, Next.js, and Tailwind CSS. Copy, customize, and build faster.

- Repository: https://github.com/anelkabag/bag-ui
- Website: https://www.bagui.pro
- Stars: 506 · Forks: 42
- Language: TypeScript
- License: MIT
- Published: 2026-09-20 · Updated: 2026-09-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/anelkabag-bag-ui

## What problem BagUi solves, and who it is aimed at

Building a landing page with shadcn/ui means assembling the same primitives repeatedly: a navbar, a hero, a feature grid, a pricing table, a footer. shadcn/ui gives you the primitives and a copy-in model, but not the assembled page sections. BagUi fills that gap with a registry of pre-built blocks and sections. The README describes it as "a modern, open-source registry of UI components, blocks, and ready-to-use sections" and lists navbars, heroes, footers, pricing tables and CTAs as the content categories.

The audience is narrow and specific. You need to be working in React or Next.js with Tailwind CSS already in place, and you need to be comfortable with the shadcn/ui registry model, where components are copied into your project rather than installed as a dependency. If your stack is Vue, Svelte or plain CSS, the registry format and the component code are both a mismatch. The project is not a general-purpose component library in the npm sense; it is a distribution channel for source files you own after copying.

## How the registry mechanism actually works

The architecture has two layers. Component source files live under registry/default, split into blocks (page sections such as navbar, hero and feature) and ui (reusable base components). A top-level registry.json file is the manifest that lists every available item. Each entry in the items array carries a name, a type such as registry:block, a title, a description, a files array with path and target, and an access object with a tier of free or pro.

The files array is the load-bearing part. The path points at the source file inside the repository, for example registry/default/blocks/navbar/navbar1.tsx. The target is the destination inside a consumer project, for example components/blocks/navbar1.tsx. When a user pulls the item through the shadcn CLI, that mapping decides where the code lands. Get the target wrong and the component appears in an unexpected directory.

On the maintainer side, package.json shows a generation step. registry:generate runs tsx scripts/generate-registry.ts, and build chains registry:generate before next build. A separate registry:watch runs scripts/watch-registry.ts, and the dev script runs the watcher and next dev together through concurrently. This means the manifest is not edited by hand at build time; it is produced by a script from the files on disk. The README, however, tells contributors to add an entry to registry.json manually. Those two accounts do not line up, and a contributor following only the README may be editing a file that the generator overwrites.

## Running BagUi locally and adding your first block

The README's Getting Started section lists Node.js v18 or later, npm (or pnpm or yarn) and Git as prerequisites. Clone the repository and install dependencies first.

```bash
git clone https://github.com/anelkabag/bagui.git
cd bagui
npm install
```

Then start the development server. Note that the dev script is not plain next dev: package.json defines it as concurrently -k "npm run registry:watch" "next dev", so the registry watcher starts alongside Next.js.

```bash
npm run dev
```

The README states the app will be available at http://localhost:3000. If you want to add a component rather than consume one, the README's rules say blocks are organised by category under registry/default/blocks, so a navbar block belongs in registry/default/blocks/navbar/navbar1.tsx. The README gives this minimal example of the component shape.

```tsx
export default function Navbar1() {
  return (
    <nav className="flex items-center justify-between p-4">
      <div className="font-semibold">BagUi</div>
      <div className="flex gap-3">Home</div>
    </nav>
  );
}
```

Before opening a pull request, the README's checklist requires both the app build and the registry build to pass.

```bash
npm run build
npm run registry:build
```

Be aware that npm run build is defined in package.json as npm run registry:generate && next build, not a bare next build, so running it regenerates the registry before compiling.

## Where the documentation stops short

The largest gap is the access tier. Every registry item carries access.tier set to free or pro, and the README's checklist tells contributors to set it, but nothing in the README explains what pro means in practice: how a pro item is gated, whether the CLI can fetch it, or what a consumer needs to do differently. The repository does contain a supabase directory and the dependencies include @supabase/ssr and @supabase/supabase-js, which suggests authentication or entitlement logic lives in the app, but the README never connects those pieces to the tier field. If you plan to consume pro items, that is the first thing to investigate in the source.

A second gap is release history. No releases were retrieved for this repository, and package.json marks the package as private with version 0.5.0. There is no published changelog to read. You cannot tell from the repository what changed between versions or whether breaking changes to component APIs are announced anywhere.

A third gap is the build-extension-vscode.md file at the repository root and the vscode directory. Neither is mentioned in the README, so a VS Code extension appears to be in progress or shipped without documentation in the main file. Treat it as unverified until you read the source.

## When BagUi is the wrong choice

BagUi is a poor fit if you need a dependency-managed component library. There is no installable npm package for the components themselves; the package is private, and the delivery model is copy-in through a registry. That means no automatic updates, no dependency resolution for the blocks you take, and no way to receive a security fix by bumping a version. You own the copied code, including its bugs.

It is also a poor fit if you are not on the shadcn/ui model. The registry format, the target paths and the components.json file at the repository root all assume shadcn conventions. A team that uses a different design system would be importing foreign conventions along with the markup.

Finally, the animation story deserves scrutiny. Framer Motion is listed in the README's tech stack, while package.json depends on motion (^13.2.0) and also on gsap, lenis, @studio-freight/lenis and tw-animate-css. That is a lot of animation surface for a component registry, and the README does not document which library each block uses or how to opt out. If bundle size matters to you, inspect the individual block before copying it rather than assuming a single animation dependency.

## How BagUi differs from shadcn/ui itself

The obvious alternative is shadcn/ui, and the difference is one of altitude rather than competition. shadcn/ui ships primitives: button, dialog, input, dropdown. BagUi sits above that layer and ships assembled sections: a navbar with its layout already decided, a pricing table with its structure already chosen. The README is explicit that shadcn/ui is the component foundation, so BagUi is not replacing it. In practice you would use both, and BagUi's blocks presumably depend on shadcn primitives being present in your project.

The trade-off is control. A primitive gives you a blank slate and you build the section yourself. A block gives you a finished section and you edit it afterwards. The second path is faster to a first draft and slower to a design that does not resemble the original. If your product has a strong visual identity, the editing cost can exceed the time the block saves. If you are building a marketing page on a deadline, it usually does not.

## Licence and maintenance cost

The repository is MIT licensed, and the README repeats that under its License section. MIT is permissive: you can use the components in commercial and closed-source projects, modify them, and redistribute them, provided the copyright notice and permission notice are preserved. The practical consequence for a registry is that copied component files retain the licence obligation, so keeping attribution in the copied source is the simple way to stay clean. This is a general observation about MIT, not legal advice for your situation.

The last push to the default branch was on 2026-09-16, and the repository is not archived. There are no retrieved releases, so the upgrade path is not a version bump but a manual diff: when a block changes upstream, you compare it against the copy in your project and merge by hand. Budget for that. The project's own contribution checklist, with its build and registry:build gates, indicates the maintainer expects changes to pass both before merging, which is a reasonable signal about the state of the main branch but says nothing about how often blocks change.

## Conclusion

Adopt BagUi if you already use shadcn/ui and want pre-built navbar, hero, footer, pricing or CTA blocks you can copy and adapt. Skip it if you need a versioned npm package with semantic-release history and changelogs, since no releases were retrieved. Before committing, verify that the registry.json entry for the block you want points at the target path you expect, and confirm whether registry:build (shadcn build) is required for your own distribution pipeline.

## FAQ

### What is BagUi?

BagUi is an open-source shadcn/ui registry of UI components, blocks and ready-to-use sections such as navbars, heroes, footers, pricing tables and CTAs. It is built with Next.js, TypeScript, Tailwind CSS and Motion, and is MIT licensed.

### How do I install BagUi and run it locally?

The README requires Node.js v18 or later, npm (or pnpm or yarn) and Git. Clone the repository, run npm install, then npm run dev, and the README states the app will be available at http://localhost:3000.

### How do I add a new component to the BagUi registry?

Place the file under registry/default/blocks or registry/default/ui in the matching category folder, then add an entry to registry.json with a unique name, the correct path, a target for the consumer project, and an access tier of free or pro. The README requires npm run build and npm run registry:build to pass before opening a pull request.

### Is BagUi free to use in a commercial project?

The repository is licensed under MIT, which permits commercial and closed-source use, modification and redistribution as long as the copyright and permission notice are preserved. Registry items also carry an access tier of free or pro, and the README does not explain how pro items are gated.

### What is a UI feature?

The README does not define this term, so it cannot be answered from the repository documentation.

## Sources

- [anelkabag/bag-ui on GitHub](https://github.com/anelkabag/bag-ui)
- [Issues](https://github.com/anelkabag/bag-ui/issues)
- [License: MIT](https://github.com/anelkabag/bag-ui/blob/main/LICENSE)
- [Project website](https://www.bagui.pro)
- [README](https://github.com/anelkabag/bag-ui/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anelkabag-bag-ui