The reason people pick Beaver Builder is that turning it off does not destroy the content. That property is worth protecting at the hosting layer too.
Most builder problems are lock-in problems. This one mostly is not, and the hosting job is to keep it that way.
Beaver Builder stores layout in meta and outputs ordinary markup, so deactivating leaves readable content rather than a page of unrendered shortcodes. Migrations are handled so that stays true.
Editing happens on the live page, which means every save is a request against the same URL visitors are loading. Those writes get room instead of queueing behind traffic.
The builder writes a stylesheet and script per page into a cache directory. Clearing it is routine, so the disk those files land on decides how the first view after a purge feels.
A saved row reused across a site invalidates every page using it. The purge is widened to match rather than clearing only the page you edited.
Layout lives in post meta, so a bad edit is a content change. Daily restore points make it reversible without touching anything else.
A builder that outputs clean markup only stays portable if nothing in the pipeline rewrites it. That is a migration and caching question, not a plugin setting.
A builder site is quick until its asset cache is cleared. What matters is how long the next visitor waits while the per-page files are written again.
Two properties drive it: the output is portable, and editing happens on the front end rather than in a separate screen.
| Setting | What we do | Why |
|---|---|---|
| Layout meta handling | Preserved intact through migrations and search-replace | The builder's selling point is that its output survives deactivation, and a careless database rewrite is the one thing that quietly removes that guarantee. |
| Front-end save capacity | Editor writes given room away from visitor traffic | Editing happens on the live URL, so a designer saving repeatedly is competing with readers for the same workers on the same page. |
| Asset cache disk | Per-page CSS and JS written to local NVMe | Clearing the builder cache is a routine action, and every page then regenerates its own stylesheet on first view. |
| Global row purge | Extended to every page using a saved row | A reused row appears across the site, so purging only the edited page leaves the rest serving the previous version. |
| Revision limit | Capped per post | Front-end editing produces revisions faster than writing does, and an unbounded post table shows up as slow admin search months later. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the site across — migration is free, layouts intact.