Data & Infrastructure Ownership
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.
What lives where
| 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.
What leaves your server
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:
- AI - prompts and the page content in context go from your server to the AI gateway or provider you configured, on your API key. ChaiBuilder is not in that path. See AI Setup.
- Stock image search - a query goes to the stock provider whose API key you set, and the image you pick is copied into your own bucket.
- Email - password resets and transactional mail go through your SMTP credentials.
- Analytics, tracking scripts, embeds - whatever you add to the site or to global data.
Remove the AI keys and the stock provider keys and the deployment makes no third-party calls at all beyond license validation.
What ChaiBuilder cannot do
- Read or write your database. It has no credentials and no network path to it.
- See your pages, drafts, media, users, or form submissions.
- Disable a running deployment. The license check gates access to new versions, not the serving of pages you have already deployed.
- Change your site. Upgrades happen when you bump the package version and deploy.
What ownership costs you
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.
Ownership and multi-tenancy
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.
Exit path
If you stop paying, or stop using the product entirely:
- The deployment you have keeps running. Your license window governs which new versions you may move to, not whether the current one runs.
- Your content stays where it always was. Pages are JSON in your own tables, media are files in your own bucket, structured content is standard Payload collections.
- The application around the builder is plain Next.js and plain Payload, both of which outlive any decision you make about ChaiBuilder.
Related
- Architecture Overview - what runs where inside the deployment.
- Environment & License - every variable, and how the license check behaves.
- Trial & Licensing - the trial, the plans, and the release window.
- Requirements - what your infrastructure needs to provide.
- Storage Configuration - wiring your own bucket.
