A modern, open-source registry of UI components, blocks, and ready-to-use sections — built to help developers ship polished interfaces faster with shadcn/ui.
Live Site · Getting Started · Contributing · Project Structure
Built by Anelka Bag
BagUi is an open-source component registry offering a growing collection of production-ready UI blocks, sections, and components — navbars, heroes, footers, pricing tables, CTAs, and more — built with a strong focus on clean design and smooth animations.
- Next.js — React framework
- TypeScript — type safety
- Tailwind CSS — utility-first styling
- shadcn/ui — component foundation
- Framer Motion — animations
git clone https://github.com/anelkabag/bagui.git
cd baguinpm installnpm run devThe app will be available at http://localhost:3000.
BagUi is open source, and contributions are very welcome! Whether it's a new component, a bug fix, or a documentation improvement — here's how to get started.
git checkout -b feat/my-new-componentComponents live in two places:
| Type | Path |
|---|---|
| Blocks | registry/default/blocks |
| UI components | registry/default/ui |
Rules to follow:
- If the component's category doesn't exist yet, create a new folder for it.
- Blocks should be organized by category, e.g.:
- Place the component file in the right folder, e.g.:
registry/default/blocks/navbar/navbar1.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>
);
}Keep it clean, reusable, and consistent with the project's existing conventions.
Add an entry for your component in the items section of registry.json:
{
"name": "navbar1",
"type": "registry:block",
"title": "Navbar Example 1",
"description": "Modern and responsive navigation.",
"files": [
{
"path": "registry/default/blocks/navbar/navbar1.tsx",
"type": "registry:block",
"target": "components/blocks/navbar1.tsx"
}
],
"access": {
"tier": "free"
}
}Checklist before saving:
-
nameis unique across the registry -
pathpoints to the correct file underregistry/default -
targetmatches the expected destination in a consumer project -
access.tieris set tofreeorpro
npm run build
npm run registry:buildThe first command makes sure the app compiles correctly. The second prepares and publishes your component to the registry.
- Commit your changes with a clear message
- Push your branch
- Open a PR including:
- the component name
- what it adds / fixes
- screenshots or a short screen recording, if possible
BagUI listens for successful GitHub deployment_status events from Vercel.
Only deployments marked as production are accepted. The publisher then reads
the canonical live registry at https://www.bagui.pro/r/registry.json; the
first synchronization records the existing catalog as a baseline without
emailing it. Later additions create unique campaigns and durable per-recipient
delivery jobs in Supabase. Ordinary resource updates, preview deployments, and
local development do not create campaigns.
Before enabling production sends:
-
Apply
supabase/release-notifications.sqlto the production Supabase project. The migration reuses the existing delivery table as the persistent queue and enables Supabasepg_netandpg_cron. New campaigns enqueue an asynchronous HTTP dispatch in the same database transaction. A conditional once-per-minute Supabase recovery task wakes due or expired deliveries if an HTTP dispatch or worker was interrupted; this is not a Vercel Cron Job. -
Set these server-side environment variables in the production deployment:
SUPABASE_SERVICE_ROLE_KEY,RESEND_API_KEY,RESEND_WEBHOOK_SECRET,RELEASE_NOTIFICATION_DISPATCH_SECRET(at least 32 random bytes),RELEASE_NOTIFICATION_WORKER_SECRET(at least 32 random bytes),NOTIFICATION_TOKEN_SECRET(at least 32 random bytes), andRELEASE_NOTIFICATION_ADMIN_EMAILS(comma-separated admin email addresses).BAGUI_SUPPORT_EMAILis optional and is used as the reply-to address. -
Add a GitHub Actions repository secret named
RELEASE_NOTIFICATION_DISPATCH_SECRETwith the same value as the Vercel dispatch secret. The workflow at.github/workflows/release-notifications.ymlmust be merged to the default branch to receive GitHubdeployment_statusevents, then callshttps://www.bagui.pro/api/notifications/publish. Confirm the Vercel GitHub integration creates GitHub deployments withproduction_environment: truefor production. The publisher independently checks the event and fetches the public production registry before creating campaigns. -
In the Supabase SQL editor, store the worker URL and the same worker secret configured in Vercel in Vault:
select vault.create_secret( 'https://www.bagui.pro/api/notifications/worker', 'release_notification_worker_url' ); select vault.create_secret( '<same value as RELEASE_NOTIFICATION_WORKER_SECRET>', 'release_notification_worker_secret' );
The database dispatches workers through
pg_net; the worker authenticates with the shared secret. Keep this value out of client-side configuration. -
Confirm that
news.bagui.prois listed as verified with sending enabled in the Resend dashboard. Public DNS currently publishes the Resend DKIM and sending/SPF records, but DNS alone cannot confirm the Resend account status. No DMARC record was found fornews.bagui.proorbagui.pro; review your DMARC policy with the domain administrator as a separate deliverability step. The worker checks the Resend account before claiming or sending any email. -
Configure a Resend webhook at
https://www.bagui.pro/api/webhooks/resendforemail.sent,email.delivered,email.failed,email.bounced, andemail.complained, then store its signing secret asRESEND_WEBHOOK_SECRET.
The deployment callback does not send emails or wait for delivery. Supabase
pg_net dispatches the secured Next.js worker after a campaign is committed.
The worker processes at most 50 recipients per invocation, applies controlled
Resend concurrency, and relies on delivery leases plus exponential retry
backoff. Supabase pg_cron is only a recovery path for pending work, so Vercel
Hobby does not need any scheduled function. Product update emails are enabled
by default for confirmed accounts without a saved preference. Existing explicit
opt-outs remain opted out; users can turn emails off or back on under
Account → Email preferences. Admins listed in
RELEASE_NOTIFICATION_ADMIN_EMAILS can inspect campaigns at
/admin/release-notifications and retry eligible temporary failures.
bagui/
├── registry/
│ └── default/
│ ├── blocks/ # UI blocks & page sections (navbar, hero, footer, ...)
│ └── ui/ # Reusable base UI components
├── registry.json # Registry manifest — lists all available components
└── public/ # Static assets
- File created in the correct folder
- Component renders and works correctly
- Component added to
registry.json -
npm run buildpasses -
npm run registry:buildpasses - Pull request opened
- Keep components simple, clean, and well named.
- Follow the existing structure to stay consistent with the rest of the project.
- Introducing a new block type? Create the matching category under
registry/default/blocksfirst. - When in doubt, look at how similar existing components are structured before writing your own.
This project is licensed under the MIT License.
Made with ❤️ by Anelka Bag — contributions welcome!

