Frappe Builder: a visual page builder that ships as a Frappe app

The problem Frappe Builder solves, and who ends up using it

The README states the motivation directly: existing solutions were "too complex, too restrictive, or difficult to integrate with the Frappe ecosystem", and pages built with them were "bloated with unnecessary scripts and styles". That is the whole thesis. Frappe Builder is not trying to be a general-purpose site builder that happens to work with Frappe. It is a Frappe app that adds a visual editing layer on top of the framework's CMS, so the page you design and the data it renders live in the same database.

The audience follows from that. If you already run Frappe or ERPNext and you need marketing pages, landing pages or content pages next to your application, Builder keeps you inside one stack instead of bolting on WordPress and syncing content by hand. The README lists designers and developers as the two intended users, and the feature set reflects both: a Figma-like editor for the first, global scripts, client scripts, per-block data scripts and typed block props for the second.

If you do not run Frappe, the calculus changes completely. Builder is not a standalone binary. Everything it does is delivered through the framework, and the installation path assumes a Frappe site exists or that you are willing to create one.

How the editor, the CMS and the published page fit together

The repository splits cleanly into a Python package at builder/ and a Vue frontend at frontend/, with frappe-ui listed as a workspace in package.json. That is the architecture in one line: server-side Frappe doctypes and APIs, client-side editor built on Frappe UI. The pyproject.toml declares frappe as a bench dependency with the range ">=15.0.0,<18.0.0", so the app is pinned to specific framework major versions rather than tracking whatever is installed.

The data flow the README describes is unusual for this category. Pages are not exported to static HTML and pushed to a CDN. They are stored and served by Frappe, which means the built-in CMS can fetch dynamic data from your database and power data-driven pages "without a separate backend". Dynamic bindings are not limited to content either: the README says you can bind any property or style to values sourced from scripts, page data or query parameters. A block's color or a section's visibility can come from the same query that fills its text.

Publishing is the other half. The README calls it "one-click publishing", and the AI agent section adds a permission model on top: reads respect your permissions, sensitive changes wait for your approval, and every AI edit is revertable. That last claim is worth noting precisely because it is scoped to AI edits. The README does not make the same promise about manual publishes, and it does not document rollback for them.

The performance argument is stated rather than measured. The README says Builder "does not bloat web pages with unnecessary scripts hence pages are highly performant, consistently scoring high on Google Lighthouse tests". Treat that as the project's design intent, not as a number you can compare across sites. What you can verify is that there is no separate static export step to keep in sync.

Installing Frappe Builder and opening the editor for the first time

There are two documented paths. The managed one is Frappe Cloud, which the README presents as the official hosting service and links from a signup page. The self-hosted production path uses the easy install script, and it is two commands. The first downloads the script:

wget https://frappe.io/easy-install.py

The second deploys it. Every parameter below is copied from the README; replace the email and the site name with your own values and leave the image and version flags as given:

python3 ./easy-install.py deploy \
    --project=builder_prod_setup \
    [email protected] \
    --image=ghcr.io/frappe/builder \
    --version=stable \
    --app=builder \
    --sitename subdomain.domain.tld

The README says this sets up a production-ready instance "in about 5 minutes". You should end up with Builder reachable at the sitename you passed.

For development, the Docker route needs Docker, docker-compose and git. Create a folder and pull the two files:

mkdir frappe-builder && cd frappe-builder
wget -O docker-compose.yml https://raw.githubusercontent.com/frappe/builder/develop/docker/docker-compose.yml
wget -O init.sh https://raw.githubusercontent.com/frappe/builder/develop/docker/init.sh

Then start the stack:

docker compose up

Wait until the terminal prints `Current Site set to builder.localhost`. The README says the site is then available at http://builder.localhost:8000, with the username `Administrator` and the password `admin`. Change those credentials before the instance is reachable from anywhere but your machine.

If you prefer a bench install instead of Docker, the README's local setup is three commands inside a frappe-bench directory, after bench itself is installed:

bench get-app builder
bench new-site builder.localhost --install-app builder
bench browse builder.localhost --user Administrator

The README's copy of that block is truncated mid-command, so treat the third line as the last step it fully documents. Note also that package.json requires Node >=20.19.0 for frontend work, and pyproject.toml requires Python >=3.10.

Where Frappe Builder is the wrong choice

The dependency is the limitation. Frappe Builder is an app inside a framework, and the framework is not optional. If your team has no Frappe instance and no appetite to operate one, you are taking on a Python web application, a database, a Node toolchain for frontend builds, and the bench or Docker workflow that ties them together, all to publish pages. A static site generator needs none of that.

The version pin cuts both ways. The declared range is Frappe ">=15.0.0,<18.0.0". Upgrading Frappe past 18 will require a compatible Builder release, and the reverse is also true: if you are stuck on an older framework line, newer Builder releases may not install. That is normal for framework apps, but it means your page builder and your application platform upgrade together.

The AI site builder has its own boundary. The README describes an agent that grounds itself in your existing site, follows your design language, reuses components and theme tokens, and researches facts online rather than inventing them. It also says sensitive changes wait for approval. That is a careful design, and it is still a language model writing page structure. The revert guarantee is stated for AI edits, which tells you the project expects those edits to sometimes be wrong.

Finally, publishing. The README does not document a rollback for a manual publish. If your workflow needs a staging-to-production promotion with a recorded diff, you should confirm that exists before you depend on it, because the README is silent on the subject.

Frappe Builder against WordPress and static site generators

The honest comparison is WordPress, because that is what most people evaluating a "website builder" already have in mind. The difference is not the editor, it is where the content lives. WordPress is a PHP application with its own database, its own plugin ecosystem and its own theme layer; integrating it with an ERP means writing against its REST API and keeping two systems in step. Frappe Builder stores pages in Frappe, so a page can query the same doctypes your application already uses. That integration is the product.

The trade is ecosystem. WordPress has a plugin for nearly everything and a hosting market that will run it for a few dollars. Frappe Builder has the Frappe app ecosystem, which is smaller and oriented toward business applications. If your site needs a specific third-party integration, check whether a Frappe app covers it before assuming you can find an equivalent.

Against a static site generator such as Hugo or Eleventy, the split is dynamic versus static. A static generator produces files you can host anywhere and serves them with no runtime. Frappe Builder serves pages from a running application, which is what lets it render database-driven content and per-block dynamic bindings. You pay for that with a server, a database and an upgrade path. If your site is genuinely static content, the generator is the simpler answer and Builder adds machinery you will not use.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-09-28. Releases are frequent: v1.34.0 on 2026-09-08, v1.33.0 on 2026-08-28, and v1.32.0 on 2026-07-30. That cadence is the maintenance story, and it also defines your upgrade cost. A project releasing roughly monthly means you either track releases or you pin and fall behind.

Upgrading is a Frappe app upgrade, so it follows the framework's rules. Because pyproject.toml constrains frappe to ">=15.0.0,<18.0.0", a Builder upgrade can be blocked by your framework version, and a framework upgrade can be blocked by Builder. Plan those together rather than treating the page builder as an independent component.

The licence is MIT, declared in pyproject.toml with license-files pointing at LICENSE, and package.json carries the same MIT identifier. MIT is permissive: you can use, modify and redistribute the code, including in commercial work, provided the licence and copyright notice are kept. That is a summary of what the identifier means, not legal advice. If you plan to redistribute Builder as part of a product, read the LICENSE file and get your own counsel.

One dependency detail is worth flagging for operators. The Python dependencies include duckdb pinned to exactly 1.4.3 and litellm pinned to exactly 1.95.0. Exact pins reduce surprise, but they also mean those packages will not move until the project moves them. If your environment needs a different version of either, you have a conflict to resolve.

Editorial conclusion

Adopt Frappe Builder if you already run Frappe or ERPNext and want a visual editor whose output is a Frappe page rather than a separate static site. Do not adopt it if you need a standalone builder that runs without the framework, or if you expect the README to tell you how to roll a publish back. Before committing, verify the supported Frappe version range in pyproject.toml, run the Docker development setup once to confirm the editor loads at builder.localhost:8000, and check whether per-page routing and dynamic detail pages fit the site you actually need to build.

Frequently asked questions

Official sources

1. frappe/builder on GitHub
2. License: MIT
3. Project website
4. README
5. Releases