Vvveb CMS: a PHP page builder for websites, blogs and shops

What Vvveb CMS is, and the problem it removes

Vvveb is a self-hosted content management system written mainly in PHP. The README describes it as a "CMS with page builder to build websites, blogs or ecommerce stores", and the repository topics list blog engine, ecommerce platform, page builder, shopping cart and website builder. That combination is the point: instead of running one tool for the marketing site, another for the blog and a third for the store, you run one PHP application and one admin login.

The audience is narrow but real. It fits a developer or small agency that hosts its own sites and wants a visual editor for client pages without giving up direct access to templates and PHP. It also fits a shop that has outgrown a static site but does not want a hosted storefront. The README claims a low resource footprint, saying it serves "hundreds of requests per second on free shared hosting" with cache enabled. That is a vendor claim, not something this article measured.

What it is not is a hosted product. There is a demo at demo.vvveb.com, but the software itself is something you upload to your own server or run in Docker. Everything below assumes you are the operator.

The page builder, the admin, and the headless APIs

The visible mechanism is the drag and drop page builder, which comes from a separate submodule, VvvebJs. The repository notes that parts of the project live in their own repositories: the admin theme, the default frontend theme, the default blog theme and VvvebJs. So the builder is not a private feature of the CMS; it is a JavaScript library that the CMS drives, and the README says it can be used independently.

Around that builder sits the admin, which the README says handles revisions, media management, multi user access and role permissions. Content types are not fixed: custom fields, custom posts and custom products are supported, which is how a blog post, a landing page and a product can share the same publishing pipeline without a schema change.

The second interface is the API. The README calls Vvveb a "Hybrid Headless CMS", usable both as a traditional CMS and as a headless one through GraphQL and REST. The repository layout backs this up: there are graphql/ and rest/ directories next to admin/, app/ and system/. That is the architecture in one line: PHP application core, admin and frontend themes on top, two API surfaces beside it.

Ecommerce is a module rather than an add-on. The feature list includes one page checkout, subscriptions, digital assets, vouchers and coupons, product options, attributes, variants, reviews and QA. Whether all of that is production ready for your tax and shipping rules is something the README does not address, and it is the first thing I would test.

Installing Vvveb: Docker, CLI install and the first login

There are three documented routes. The README says you can clone the repository and build it, download the latest release, or use Docker. The Docker route is the fastest to a running instance because the compose file brings up the database, PHP and phpMyAdmin together.

The compose file maps the app to port 8080, so after starting it you open http://localhost:8080. It also sets the database credentials as environment variables, including DB_ENGINE: mysqli and the VVVEB_HOST and VVVEB_PASSWORD pair.

services:
  php:
    image: vvveb/vvvebcms:latest
    environment:
      DB_HOST: db
      DB_DATABASE: vvveb
      DB_USER: vvveb
      DB_PASSWORD: vvveb
      DB_ENGINE: mysqli
    ports:
      - "8080:80"

Start it with `docker compose up`. The compose file leaves auto install commented out, so the first request to the site should send you to the installer. If you prefer to skip the web installer, the README gives a command line install:

php cli.php install module=index host=127.0.0.1 user=root password=1234 database=vvveb admin[email][email protected] admin[password]=admin engine=mysqli

Replace engine with sqlite or pgsql if you prefer, as the README states. Note that the admin email and password are passed as array style arguments, admin[email] and admin[password]; they are not flags. After install, the admin lives under /admin, and the README links an admin login page in its demo section.

If you build from source instead, the README requires git 2.13 or newer for `git clone --recurse-submodules https://github.com/givanz/Vvveb`, and older git versions should use `git clone --recursive`. The submodules matter: skip them and the admin theme and page builder will be missing. To package a release for upload, the repository has a build script, `./build.sh`, which the README says produces vvveb.zip.

Where Vvveb stops being the right tool

The AGPL-3.0 licence is the first hard boundary. If you modify Vvveb and let users interact with it over a network, the licence's network clause applies to your modified version. For a company that wants to ship a closed source derivative, this is a blocker, not a detail. The README states the licence as "GNU Affero General Public License Version 3 (AGPLv3) or any later version" and does not offer an alternative licensing path.

The second boundary is the ecosystem. The README mentions a themes and plugins marketplace with one click install from the admin dashboard, but it does not document the size of that marketplace or a review process for third party plugins. Anyone coming from WordPress should assume fewer ready made extensions and budget for custom plugin work through the event system the README describes.

The third is operational. The README says installation is easy and that a secure install exposes only one PHP file to the public, which reduces attack surface. That is a design claim, and it also means the shape of your web server configuration matters. The repository ships apache-vvveb.conf, nginx-live.conf and nginx-live-nocache.conf, so the project expects you to place those directives rather than rely on a generic PHP host. On shared hosting where you cannot edit the vhost, that can be the difference between working and not.

Finally, the README does not document rollback or downgrade steps for a failed upgrade. Backups are listed as a feature, manual and automatic, and that is the mechanism you would lean on, but the upgrade path itself is not spelled out in the README.

Vvveb vs WordPress and other PHP CMS options

The comparison people search for is Vvveb vs WordPress, and the honest difference is not features, it is weight and control. WordPress is a mature ecosystem with a huge plugin and theme market and a block editor. Vvveb is a smaller project whose selling point in its own README is a drag and drop page builder plus a low resource footprint, with a claim of serving hundreds of requests per second on free shared hosting when cache is on. If your constraint is a cheap host and a small footprint, that claim is the reason to look at Vvveb at all.

The second alternative is going headless with a dedicated CMS and a separate storefront. Vvveb covers that case with its GraphQL and REST endpoints, but it does so from inside the same PHP application, which means the CMS and the shop share a database and a deployment. A standalone headless CMS plus a separate commerce backend gives you independent scaling and independent failure, at the cost of two systems to run.

Against a static site generator, the difference is editorial. A generator gives you speed and version control but no admin, no roles and no checkout. Vvveb gives you the admin and the checkout, and you trade away the simplicity of a build step. Pick based on who edits the site: if it is a developer with a git client, a generator is less machinery. If it is a client with a browser, Vvveb is the more direct answer.

Maintenance, upgrades and licence cost

Maintenance looks steady rather than dormant. The repository is not archived, and the last push was on 2026-08-05. Recent releases are close together: 1.0.8.4 on 2026-05-28, 1.0.8.5 on 2026-06-07 and 1.0.8.6 on 2026-06-11. That cadence suggests point releases arrive every few weeks, though the release notes are not described here, so read them before upgrading a live site.

The upgrade cost is mostly environmental. Because the project depends on submodules for the admin theme, the frontend theme, the blog theme and the page builder, pulling the main repository without `git pull --recurse-submodules` and `git submodule update --recursive --remote` leaves you on old theme and builder code. That is a real operational trap on a source based deployment. Docker users sidestep it by pulling a new image, but then the theme and builder versions are tied to whatever the image ships.

Server side, the Dockerfile targets php:8.3-fpm and installs gd with webp and jpeg support, plus xml, dom, curl, mbstring, intl, gettext, zip, apcu and mysqli. Note that sqlite3 is commented out in that image, even though the README lists sqlite as a supported database engine. If you want SQLite under Docker, you would need to build your own image rather than use the published one.

On licence cost, AGPL-3.0 means no licence fee, and the README asks for support through PayPal donations or Open Collective sponsorship. The obligation is disclosure of modifications for network served code, not payment. That is a summary of what the repository states, not legal advice; get counsel if you plan to distribute a modified version.

Editorial conclusion

Adopt Vvveb if you want a self-hosted PHP CMS where the page builder, blog and shop live in one admin, and you accept AGPL-3.0. Do not adopt it if you need a hosted service, a large third party plugin market, or a stack that is not PHP. Verify first that your PHP version and database driver match the requirements, and that your server can run the one-file front controller setup described in the install docs.

Frequently asked questions

Official sources

1. givanz/Vvveb on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases