A ChaiBuilder site is a plain Next.js application you own and run, with three parts working together: the visual builder, a CMS for structured content, and your own database and hosting. Nothing runs on ChaiBuilder's infrastructure — you're shipped code, not a hosted service.

The three pieces

1. The visual builder (chaipro)

chaipro is the builder package — client and server — installed into your Next.js app. The client side is the visual editing surface where pages are built; the server side persists those pages, registers page types, and powers the AI assistant. ChaiBuilder keeps its own set of database tables to manage pages.

2. The CMS (Payload, out of the box)

Structured content — blogs and similar collections — lives in Payload CMS, which ships with the starter. Payload's collections are independent of ChaiBuilder's page tables: there's no hard relation between them. Payload is the default, but the CMS is swappable — the builder doesn't require it, so you can plug in another CMS if you prefer.

3. Your database and infrastructure

You bring your own storage — SQLite, either a local file or a remote libSQL / Turso database — and your own hosting. All website content, registered users, and actions live in your database. ChaiBuilder has no access to it. This is the core of the product: you own the data and the infrastructure around it.

How the builder and CMS fit together

The visual builder and the CMS are wired together so they understand each other's structure and can interact — visual pages reference and surface structured content from the CMS, while each maintains its own storage. Think of it as: visual pages in the builder, structured content in the CMS, both persisted to your database.

Your Next.js app (you host it)
├── chaipro (builder)        → visual pages  ─┐
│    ├── client: editing UI                    │
│    └── server: page storage, page types, AI  ├──► Your database
├── Payload CMS              → structured content ┘   (Postgres / SQLite / …)
└── Your custom code         → routes, collections, blocks

How pages render

Pages are optimized for content-heavy, public-facing sites, using an SSG + ISR model:

• Pages are not built at build time. Each page is built on a visitor's first visit, then cached.
• When you publish a page, that page is automatically invalidated and revalidated, so visitors get the new version without a full rebuild.

Where developers plug in

Because the deployment is just Next.js + Payload, you keep full control:

• Next.js — override pages, add custom routing, build custom solutions on top.
• Payload — add custom collections and logic (it's pure Payload CMS).
• Builder — add custom blocks and custom panels to extend the editing experience.

What's open source vs paid

• Open source — the pure client-side builder component. It has no understanding of a server; whoever uses it implements their own.
• Paid (chaipro) — the open-source client plus the server layer that makes it a complete, persistable product (page storage, page types, AI, and more).

Next

• Quickstart — scaffold with npx chaibuilder-app create, deploy, and build your first page.
• Architecture Overview — the client/server split in depth.
• Rendering Model — SSG + ISR and cache invalidation.