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.
Everything you do in the builder happens to a draft. The live site keeps serving the last published version until you publish. That separation is what makes it safe to work on a page during business hours.
ChaiBuilder keeps two copies of every page and of the site settings: the draft you edit and the published copy the site serves. Publishing copies draft over live. Nothing else moves between them - there is no partial publish of one block, and no way to edit the live copy directly.
The same split covers the theme and design tokens, which are published separately from pages.
Saving is not publishing. A save updates the draft only.
The builder autosaves as you work - after a handful of edits, and at most once every few
seconds. The topbar Save button shows the current state (Save draft / Saving /
Saved) and forces a save when you want one. If you try to close the tab with unsaved
changes, the browser warns you.
Saving runs the page structure check first. If there are errors or warnings you get a dialog listing them with the option to Save anyway.
When another editor has the page open, the topbar controls are hidden entirely - you cannot save, publish, or preview a page someone else is editing. See Page locking.
The Preview button opens the page in a new tab in draft mode - the real site, rendered from your unpublished draft, at the real URL. This is the right way to check a page: the builder canvas is an approximation, the preview is the actual output.
While draft mode is on, an amber "Draft mode is active" badge sits in the corner of every page you visit, with a Disable button to leave. Analytics and tracking scripts are suppressed in draft mode, so previewing does not pollute your numbers.
The Open live page link next to it does the opposite - leaves draft mode and shows what visitors currently see. Comparing the two tabs is the quickest way to answer "did that change actually ship?"
Draft mode persists in your browser until you disable it. If a page looks wrong days later, check for the amber badge before investigating anything else.
The publish button tells you where the page stands:
| Button | Meaning |
|---|---|
| Publish (plain) | Never published |
| Published (green) | Live, no pending changes |
| Publish (blue) | Live, with unpublished changes |
Publishing always saves first, so there is no "did I save?" step.
Before it goes through, you may see:
The chevron beside the button opens more:
A bulk publish modal exists for publishing several pages at once, listing everything with pending changes plus pages that are offline. It is off by default and enabled per project.
There is no scheduled publishing. Nothing can be queued to go live at a future time; publish is immediate.
Theme and design token changes are site-wide and are published from the dropdown, not the main button. Two things to know:
They travel together. Publishing the theme also publishes any pending design token changes, and vice versa - both actions push the whole site settings record live. Review both before publishing either.
Other site settings ride along silently. Settings beyond the theme and tokens are carried live by the same action without appearing as a pending change first. If someone changed a site-level setting, it ships the next time anyone publishes the theme.
Unpublish page removes the page from the live site. The draft is untouched, so the page stays in the builder and can be republished. Unpublishing a page also removes its translations from the live site.
Unpublishing is the correct way to retire a page - deleting it removes the draft too, and takes its history with it.
Published pages are served from cache. Publishing invalidates the cache for the page, its compiled styles, and any page that embeds it as a partial, then re-warms the affected pages in the background so the first visitor after a publish does not pay the rebuild cost.
For most sites this is invisible and correct. If a change does not appear on the live site after publishing, the usual causes in order are: browser cache, a CDN in front of the site, and draft mode still being on in that tab. See Caching and revalidation.
| Indicator | Meaning |
|---|---|
| Green dot | Published |
| Grey dot | Never published, or taken offline |
| Amber pencil | Published, with unpublished changes |
A never-published page shows a grey dot and no pencil, which is worth knowing - "no pencil" does not mean "nothing to publish."
Publishing requires the publish permission for pages, which is separate from the permission to edit them - a role can be allowed to build and save while someone else reviews and publishes. Unpublishing is a separate grant again. See Roles and permissions.
Publishing a translation publishes the default-language page too. The shared content lives on the default page, so it has to go. Any unrelated draft edits there ship with it - see Multilingual.
Publishing does not publish your CMS content. Payload collections have their own draft and publish lifecycle. A page bound to a blog post that is still a CMS draft will render empty even after the page is published. Publish both.
Publishing a clean page still republishes it. The button is not disabled when there is
nothing to ship; clicking Published re-copies the page and re-invalidates its caches. Not
harmful, just not a no-op.
Pages locked by another editor do not appear in the bulk publish list. If a page you expect to see is missing, check whether someone has it open.
Publishing several pages at once is not atomic. If one fails, the others may still have gone through. Re-check the list rather than assuming all-or-nothing.
