Should I vibe code
Open-source visual builder with cloud projects, CMS connections, and hosting
It's AGPL and self-hostable. Its own docs say don't self-host the builder in production. Believe the maintainers.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Start where the other open-source cloud entries start: do not clone it, run it — the builder is AGPL, actively developed and sitting on GitHub. Then read the project's own self-hosting page, because it says something the Activepieces and Appsmith entries did not get to say. Webstudio's maintainers recommend self-hosting the builder for development only, and describe production builder self-hosting as not recommended. What they do want you to self-host is the output: export a project with the CLI and deploy it yourself to Netlify, Vercel, Cloudflare Pages, GitHub Pages, or your own box via Coolify. That reframes the whole question. The honest DIY route here is not a visual editor and not a compose file — it is a publishing pipeline, plus the discipline to get your projects out of Postgres and into git. Ignore that and you become the operator of the one component the authors advise against operating, holding the only copy of every project you have ever designed, plus the write tokens for whichever headless CMS each of those sites reads from. The sting is how quiet the failure is: published sites are static artefacts on a CDN, so they keep serving perfectly while their source is gone.
What actually breaks
not "if". the specific failures.
- The project database, which is the only copy of every design. Sites live in Postgres, not in files, and a published site is a build artefact — lose the database and the sites stay up while the source is gone, which is the worst possible ordering because nothing alerts
- CMS connection tokens. The value of this builder is that it reads from Supabase, Contentful, Strapi, Sanity and friends, which means your instance is a box holding write credentials for other people's content stores
- Form submissions, once you leave the free tier's 300-a-month ceiling behind. Your own endpoint has no ceiling, no rate limit, no retention rule and no owner
- Certificate renewal on client domains, presented to every visitor as a full-page browser warning rather than a quiet error
- Bandwidth. Cloud meters page views at 100,000 a month with paid overage; a self-hosted origin has no meter, so a scraper or a viral week becomes an invoice or an outage instead of a line item
- Upgrades against a codebase that moves weekly. This is a live project with a fast-moving builder, and self-hosting it means tracking that pace forever or freezing on a version whose bugs are yours
- Export fidelity, in both directions: atomic CSS and generated class names mean the thing you designed and the thing you deployed are related by a build step you now own
- The staging step, which Pro has and your instance does not, so your only preview environment is the client's live domain
- Monitoring, because uptime checks on the published sites tell you nothing about the builder. The two fail independently and only one of them is visible
The upgrade goes in on Friday because the changelog mentions a fix you want. The migration runs, the container comes back, the builder loads, and eleven of the twelve projects open fine — the twelfth, the one belonging to the client who pays the most, shows an empty canvas. Nothing pages you, because every one of those twelve sites is static output on a CDN and all twelve are serving happily to visitors. You find out on Tuesday, when the client asks for a price change on one page, and you discover in that order: that the backup job has been failing since a disk warning in June, that nobody noticed because the failure was an email to an address nobody reads, and that a published site cannot be turned back into an editable project. The site is live and correct. It is also, from now until somebody rebuilds it by hand, permanently frozen.
Is that you?
the verdict is a default, not a law
- You use the free Hobby tier for the builder and take the output out with the CLI — that is the project's own recommended path and it costs nothing
- Exports land in git on a schedule, so the design is a file you have rather than a row you hope for
- Deploys go to managed static hosting, so a failed publish leaves the previous site serving
- The sites are yours, and downtime is an inconvenience rather than someone else's revenue
- You are running the builder in production against the maintainers' explicit advice, on one box, as the only person who could restore it
- Client projects exist only in a Postgres whose restore has never been tested
- CMS write tokens live on the same host as the builder, in a .env beside the compose file
- Non-technical clients log in to edit, which makes your instance's uptime their business hours
- You expected 'open source' to mean the operational risk went away rather than moved onto you
If you build it anyway
the checklist, then the prompt that enforces it
- Do not write a visual builder. GrapesJS has been at it for a decade and Webstudio is AGPL and free — whatever you write will be a worse editor with no publishing pipeline.
- Do not self-host the builder in production either. The maintainers say development only, and they are the people who know which parts are load-bearing.
- Make export the first automation you build, not the last. A scheduled CLI export into git turns the project database from a single point of failure into a cache.
- If you do run it anyway: Postgres backups with a restore you have actually performed, before the first client project goes in. The run of this failure mode is silent, so the restore is the only control that works.
- CMS tokens and the encryption key come from a secrets manager, not a .env next to the compose file, and the rotation procedure is written down before the first connection is added.
- Monitor the builder separately from the published sites, with an alert that reaches a phone. Static sites keep serving through a total builder outage, which means uptime checks will lie to you.
- Put a bandwidth or request cap in front of self-hosted origins, and know what happens when it is hit. Cloud's page-view meter is a feature, not a tax.
- Keep every custom domain in the owner's registrar account and automate certificate renewal with monitoring on the renewal job at 30, 14 and 3 days.
- Treat form submissions as personal data on the day you add the form: retention window, deletion path, rate limit, honeypot.
I am considering owning the visual site builder instead of paying for Webstudio
Cloud. Start by narrowing what I am allowed to build.
1. First, say this plainly: Webstudio is AGPL and free, and its own docs
recommend self-hosting the builder for development only, not production. The
supported self-hosted artefact is the exported site, not the editor. Only
continue if I acknowledge that.
2. So this project is a publishing pipeline, not an editor. Build the CLI export
on a schedule into a git repository first. A design that lives only in
Postgres is the failure this whole page is about.
3. Then deploy targets: static output to managed hosting with atomic deploys, so
a failed publish leaves the previous site serving. Tell me which features a
static export loses — dynamic pages, redirects, webhook forms, image
optimisation — before I choose.
4. If I insist on hosting the builder too, backups come next and nothing else
ships until I have restored one and opened a project from it.
5. Take the encryption key and every CMS token from a secrets manager, not a
.env beside the compose file, and write the rotation steps before the first
connection exists. These are write credentials for content I do not own.
6. Monitor the builder separately from the sites, alerting to a phone, and
explain why an uptime check on a published site cannot detect a dead builder.
7. Put a bandwidth or request ceiling in front of any origin I run, and tell me
what happens when it is reached.
8. Custom domains stay in their owner's registrar account. Certificates renew
automatically with monitoring on the renewal job at 30, 14 and 3 days.
9. Any form gets a rate limit, a honeypot, a size cap, a retention window and a
deletion job in the same commit as the endpoint.
10. Out of scope, and say so rather than half-building: the visual editor,
real-time collaboration, the CMS integrations, multi-seat workspaces.
11. Finish by telling me Hobby is free and Pro is $15 a month billed yearly,
then asking which of those I am actually trying to avoid paying.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment a site belongs to someone who is not you. Fifteen dollars a month billed yearly buys custom domains, certificates, a staging publish, backups, CMS connections, a metered bandwidth ceiling that turns a scraper into a line item, and a Postgres you are not responsible for restoring. And notice the number below it: Hobby is free, with unlimited projects and pages, so the cheapest correct answer for a personal site is to use their builder and export the result. The subscription is not buying you software you could write — it is buying you out of being the operator.
$15/mo is cheaper than your weekend.
This is the rare entry where the exit is the recommended architecture. Export every project with the CLI on a schedule into git, and keep a static build of each site alongside it — then the builder is disposable, the host is disposable, and moving is a re-deploy rather than a rescue. Do that from day one, because the trap is not the licence or the vendor, it is the day you discover that twelve projects exist only as rows in a database you were going to back up soon. Keep a written inventory too: every custom domain and its registrar, every CMS connection and its scopes, every host. Nobody has that list until the morning they urgently need it.
The product itself: AGPL-licensed visual builder whose docs recommend self-hosting the builder for development only, with full CLI export of the sites it produces.
Long-running open-source web builder framework, and the honest measure of how much work a visual editor really is.
Questions
It is open source, so why not just self-host it?
Because the people who wrote it advise against self-hosting the builder in production, and they are better placed than either of us to know why. Their supported self-hosting story is the published site: export it and deploy it anywhere, including your own hardware. That leaves the builder as a service you rent — free on Hobby, $15 a month billed yearly on Pro — and the interesting engineering as the pipeline that gets your work out of it, which is exactly the project worth building.
How is this different from the Activepieces Cloud entry?
The advice inverts. Activepieces says run ours rather than clone ours, and the risk you inherit is queues, webhooks and backups. Webstudio says run our output rather than our builder, and the risk you inherit is that the design of every site you have ever made lives in a database, while the sites themselves are already static and portable. One is an operations problem you take on deliberately; this one is a data-custody problem you take on by accident.
What actually breaks first?
The backup, followed by your ability to detect that it broke. This failure mode is unusually quiet: published sites are static artefacts served from a CDN, so a dead builder or a corrupted project is invisible to visitors and invisible to uptime monitoring. You find out at the next copy change, which might be weeks later, and a published site cannot be turned back into an editable project. Scheduled export into git is the single control that makes this survivable.
Is the $15 figure reliable?
It is the number the page renders, and it is the yearly-billed rate. The pricing page has a monthly/yearly toggle but only ever displays "$15/month billed yearly" for Pro and "$35/month billed yearly" for Team, so the month-to-month figure could not be read and confidence is recorded as medium rather than high. Treat $15 as a floor, and remember page views are metered at 100,000 a month with $20 per additional 100,000.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Building the site is the good weekend. Building the editor your client logs into on Tuesday is the bad decade.
Figma is absolute positions at one width. The web reflows at all of them. An importer is a guess, not a conversion.
Activepieces is MIT, so don’t build it — run it. Then answer the real question: who gets paged at 4am?
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice