Vvveb: A PHP CMS With a Page Builder, an Ecommerce Module and an AGPL Licence
Powerful and easy to use cms to build websites, blogs or ecommerce stores.
At a glance
- What is it?
- Vvveb bundles a drag and drop page builder, blog and shop modules, and a GraphQL/REST layer into one PHP application installed from a single exposed file. The trade-off is AGPL-3.0 and a codebase that is mostly HTML templates and submodules.
- Who is it for?
- Adopt Vvveb if you want one PHP install that covers a marketing site, a blog and a small shop, and you accept AGPL-3.0 terms. Do not adopt it if you plan to ship a closed source product built on top of it, or if your team has no PHP hosting at all.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 41 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Vvveb targets: one PHP install for site, blog and shop
Most self-hosted PHP options force a choice early. WordPress covers blogs and, with WooCommerce, shops, but the page editing experience is a separate plugin stack. Dedicated page builders such as the standalone VvvebJs library edit HTML and stop there, leaving content storage, users and checkout to someone else. Vvveb's pitch is that the page builder, the blog, the product catalogue and the checkout live in the same application and the same admin dashboard. The README lists multi site support, multi language support, revisions, media management and role permissions as one set of features, and ecommerce features (one page checkout, subscriptions, digital assets, vouchers, product options, variants, reviews) as another set inside the same install. The intended user is a developer or small agency deploying on shared hosting who wants a single codebase to hand to a client, not a stack of plugins with separate update cycles. The repository's primary language is listed as HTML, which tells you where the centre of gravity is: themes and templates, with PHP behind them.
Page builder, themes and the submodule split
The drag and drop editor is not a monolith inside this repository. The README states that parts of the project have their own repositories usable independently: the admin theme (Vvveb Admin Bootstrap 5 Template), the default frontend theme (Landing Bootstrap 5 template), the default blog theme (Minimal Blog Bootstrap 5 template) and the page builder itself (VvvebJs, a drag and drop website builder JavaScript library). That is the architecture to understand before you clone. The main repository is the CMS core plus glue; the visible editing surface is loaded from submodules. The build instructions reflect this: git clone --recurse-submodules for git 2.13+, or git clone --recursive on older versions, followed by git pull --recurse-submodules and git submodule update --recursive --remote when you want updates. If you clone without the submodule flags you get a repository that builds but does not contain the themes or the builder, and the failure will look like a broken admin rather than a missing clone flag. The README also describes a hybrid headless mode: the same install can serve traditional rendered pages or expose content over GraphQL and REST. That matters if you want to reuse the catalogue or posts in a separate frontend later without migrating data.
Requirements and the install path you actually type
The system requirements are explicit. PHP 7.4 minimum, PHP 8.3+ recommended, with mysqli, sqlite3 or pgsql plus xml, pcre, zip, dom, curl, gettext and gd or imagick. Databases supported are MySQL 5.7+ or MariaDB 10.2+, SQLite, or PostgreSQL 11+. Two install routes are documented. The browser route is to build or download a release, upload the files, open the site root and follow the installation instructions at docs.vvveb.com/installation. The command line route is a single call:
php cli.php install module=index host=127.0.0.1 user=root password=1234 database=vvveb admin[email]=admin@vvveb.com admin[password]=admin engine=mysqli
The README notes you can replace engine with sqlite or pgsql. To produce an uploadable archive there is ./build.sh, which the README says builds vvveb.zip. One security claim is worth repeating precisely because it shapes deployment: the README states that a secure install exposes only one php file to the public, minimising attack surface. If your deployment process assumes a web root full of PHP entry points, that assumption does not hold here, and the admin login page is described as hidden rather than at a predictable path. Plan your reverse proxy and backup rules around the actual document root, not around a typical CMS layout.
Where Vvveb is the wrong tool
The licence is the first hard boundary. Vvveb is AGPL-3.0 or any later version. If you modify it and let users interact with it over a network, the AGPL's network clause applies to your modified version, which is a different obligation from a permissive licence and a different one from the GPL alone. For a client site where the client is happy to receive the source, that is workable. For a proprietary SaaS built by forking the CMS, it is a problem you should resolve with a lawyer before writing code, not after. This is not legal advice; read the licence text. The second boundary is the feature list itself. Subscriptions, vouchers, digital assets, product variants, reviews and QA are listed as ecommerce features, but the README does not describe tax handling, shipping carrier integrations, or payment gateway coverage. If your shop needs multi warehouse inventory or carrier rate negotiation, verify those exist in the admin before you commit, because the README does not claim them. Third, the performance statement in the README (cache enabled, as fast as a static website; hundreds of requests per second on free shared hosting) is a vendor claim with no methodology attached. Treat it as a design goal, not a measured result, and benchmark your own templates. Finally, the repository is HTML-first. If your team writes only TypeScript and expects a typed API surface, the template layer will feel foreign.
How it compares with WordPress and with a headless CMS
The closest comparison is WordPress, and the difference is structural rather than cosmetic. WordPress splits into core plus plugins plus a theme, and its editor is a block editor tied to post content. Vvveb ships the page builder as a first class module with its own repository, and the admin, frontend and blog themes are separate submodules you can update independently with git submodule update --recursive --remote. The other comparison is a headless CMS such as a content API service. Those give you an API and no rendering. Vvveb's README describes a hybrid: rendered pages by default, GraphQL and REST available from the same install. That is the actual differentiator, and it is also the source of coupling. You get the shop, the blog and the builder in one database, which means one backup, one upgrade path and one set of permissions. You also get one point of failure, and a plugin ecosystem that the README says is installable with one click from the admin dashboard, which is convenient and also means you should know what a click fetches before you click it on a production server.
Maintenance, releases and the cost of the submodule model
The release cadence visible in the supplied material is tight: 1.0.8.4 on 2026-05-28, 1.0.8.5 on 2026-06-07, 1.0.8.6 on 2026-06-11. Patch releases inside a two week window suggest active maintenance, and the last push to the default branch is 2026-08-05. The cost side is the submodule layout. Updating a Vvveb install is not only pulling the main repository; the README's own update commands include git submodule update --recursive --remote, which means theme and builder changes arrive through a second mechanism. If you fork the Landing theme to customise a client site, that fork now diverges from the submodule and every upstream update becomes a merge. Budget for that or vendor your customisations as a separate theme directory rather than editing the submodule in place. The README also mentions manual and automatic backup plus import/export for migration, which lowers the cost of moving between hosts, but the shape of the export format is not described in the material provided, so test a round trip on a staging copy before relying on it. On licensing cost: there is no paid tier mentioned, only PayPal donations and Open Collective sponsorship, so the financial cost is hosting and your time, and the legal cost is AGPL compliance.
Editorial conclusion
Adopt Vvveb if you want one PHP install that covers a marketing site, a blog and a small shop, and you accept AGPL-3.0 terms. Do not adopt it if you plan to ship a closed source product built on top of it, or if your team has no PHP hosting at all. Before committing, verify the cli.php installer against your target database engine, check that the bundled submodules (the admin theme, the Landing frontend theme and VvvebJs) are present after your clone, and confirm what the marketplace one click install actually pulls onto your server.
Community notes