The Visual Website Builder
You Actually Own. React + Next.js, low-code, self-hosted. Your data, your infrastructure, every feature included.
© ChaiBuilder. All rights reserved.
Hosted builders keep your content on the vendor's servers and rent it back to you. ChaiBuilder inverts that: you are shipped an npm package that runs inside your Next.js application, on your database and hosting. The vendor has no runtime role in serving your site.
This page is the honest accounting of that claim: what lives where, what leaves your server, and what you are now responsible for.
| Thing | Where it lives | Who can read it |
|---|---|---|
| Pages, blocks, draft and published versions | Your database, in ChaiBuilder's tables | You |
| Site settings, theme, design tokens | Your database | You |
| Structured content (blog, legal, custom collections) | Your database, in Payload collections | You |
| Media files | Your object storage bucket (S3, R2, or any S3-compatible) | You, plus whoever you make the bucket public to |
| Media metadata | Your database | You |
| Registered users and sessions | Your database, via your own auth | You |
| Form submissions | Your database | You |
| Secrets (database URL, Payload secret, storage keys) | Your hosting platform's environment | You |
| Server logs | Your hosting platform | You |
There is no ChaiBuilder account behind any of this. There is no dashboard on our side showing your pages, no export step to get your content, and no data to migrate if you leave: your content is already rows in a database you administer.
Being specific matters more than being reassuring, so here is the full list.
License validation. Your deployment validates its license in the background against ChaiBuilder's endpoint, sending the license key and the domain it is running on. This is the only call the product makes to ChaiBuilder infrastructure, and it needs outbound HTTPS. If validation fails or the license lapses, the builder shows a renew or downgrade notice - published pages keep serving. See Environment & License.
Whatever you configure. Everything else that goes out is something you chose and hold the credentials for:
Remove the AI keys and the stock provider keys and the deployment makes no third-party calls at all beyond license validation.
Owning the stack is a real trade, not a free win. The work the vendor used to do is now yours:
| You now own | What that means in practice |
|---|---|
| Backups | Your database and bucket need a backup policy. Nobody else has a copy of your content. |
| Migrations | Upgrading the package can add tables or columns. You generate and run migrations as part of a normal deploy. |
| Upgrades | You choose when to move versions. Staying on an old version is allowed and sometimes correct. |
| Uptime | Your hosting choice determines your availability, and page caching determines how gracefully you degrade. |
| Secrets | The license key, database URL, and storage credentials are yours to rotate and protect. |
| Auth decisions | Auth is agnostic. Whichever provider you bring, its security posture becomes yours. |
If none of that is appealing, the honest answer is that a hosted builder may suit you better. The trade is worth making when data residency, compliance, cost at scale, or the need to extend the platform in code outweighs the operational load.
One database can host many sites. Each site is a row in the apps table, and all of its pages,
assets, and scoped collections are keyed to it. A single-site deployment pins itself to one row
via CHAIBUILDER_APP_KEY.
This is why running fifty client sites does not mean fifty databases - and also why the app key matters: point a deployment at the wrong row and it serves the wrong site's content.
If you stop paying, or stop using the product entirely:
