# VaahCMS pairs Laravel with a headless CMS and lets each module bring its own frontend > VaahCMS is a Laravel-based application platform that ships with a headless content management system, and its structural choice is that a module or theme can be written with plain Blade files or can carry its own JavaScript application, with Vue or React inside it. The install is a single npx command, and the project is MIT licensed and built by a web agency in Delhi. **webreinvent/vaahcms** — VaahCMS is a laravel based open-source web application development platform shipped with a headless content management system (CMS). - Repository: https://github.com/webreinvent/vaahcms - Website: https://vaah.dev/cms - Stars: 573 · Forks: 25 - Language: PHP - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/webreinvent-vaahcms ## The problem it names is the CMS fighting the application VaahCMS is described as an open-source web application development platform shipped with a headless content management system, and the question it asks in its Why section is the one every Laravel developer has asked. How many times have you used a CMS to build a website and Laravel for application development? Everytime, isn't it? And the answer it gives is that next time you do not have to. Use VaahCMS in your next project and develop applications with content management that doesn't come in your way. That framing is the whole product in one sentence. The alternative to a Laravel application with content in it is usually two systems, a CMS for the content and an application for everything else, with two deployment pipelines, two admin interfaces and a boundary to design. VaahCMS's pitch is that both live in one Laravel application, and the content part is headless so it does not dictate your frontend. The stated purpose is enterprise level software applications which are manageable, extendable, flexible, upgradable and maintainable in the long run. Those five words are the design brief, and each of them is a constraint on the architecture. The project is PHP, MIT licensed, with the default branch 2.x and the homepage at vaah.dev/cms. The last push was on 2026-04-09, and the recent releases are v2.3.4 from 2025-11-04, v2.3.3 from 2025-11-03 and v2.3.2 from 2025-10-25, which is a rapid patch cadence on a minor line. It is built by WebReinvent, a web agency based in Delhi, India, and the agency publishes a set of open source projects on GitHub. ## HMVC with modules and themes, and the choice of Blade or a whole frontend The architectural pattern is named in the first paragraph: Hierarchical Model View Controller, HMVC, which supports multiple Modules and Themes. The interesting sentence is the one about how each module and theme is set up. Each module and theme can be set up with just Blade files support, or can have its own frontend JavaScript library such as Vue or React. That is a genuinely unusual degree of freedom for a CMS platform. Most module systems in a Laravel application assume one frontend stack for the whole application, so a module either renders Blade templates into the host layout or brings a mini application with its own build step. VaahCMS says both are supported and the choice is per module or per theme. The stack is named too: Laravel, Vue, Pinia and PrimeVue. Vue with Pinia for state and PrimeVue for the component set, and the topics also list Vuex, Buefy and Bulma, which suggests earlier iterations of the admin frontend used those and the current one has moved on. The headless part has a specific shape. It ships with a headless CMS with a built in API, so you can plug and play with any frontend framework like Nuxt or Next. That is the part that addresses the original problem directly: the content is available over an API, so the presentation can live in a separate application with a completely different stack, and the Laravel application does not have to be the frontend at all. And the CMS Module is inspired from the simplicity of WordPress, which is the one comparison the project draws. WordPress's model is a small content core with plugins around it, and that is the shape being aimed for here. ## The install is one command The Quick Start section is a single line: ```shell npx vaah cms:install ``` That is a reasonable thing to be able to say for a Laravel package, because the usual steps are create a Laravel application, require the package, run the installer, and wire the front end. The npx route suggests the project is published to npm as a CLI as well, which lets the installer pull the frontend assets and set up the module and theme directories as part of the same command. Beyond that, the documentation is hosted on a separate versioned site at docs.vaah.dev/vaahcms-2/, with the 2 in the path naming the major version, which tells you the docs are maintained per release line rather than as one moving target. There is also a separate documentation repository, vaah-docs, and the project asks for pull requests against it, which is a useful signal about how the project expects to be worked on. A CMS platform with a separate docs repository and a Slack community is a project with a community practice around it. The Slack invite is linked from the README, alongside the GitHub link for contributing and raising issues, and the official website is the third entry point. So the three usual places for a project like this are all populated: a repository, a chat and a documentation site. ## The repository layout is a CMS with far more in it The top-level entries show what is actually in the package, and it is considerably more than a CMS. There are the Laravel application directories you would expect. Http/ for controllers and middleware, Routes/, Models/, Database/ for migrations and seeds, Config/, Console/ for commands, Facades/ with a VaahCmsFacade.php, Helpers/, Providers/ with VaahCmsServiceProvider.php, and the top-level VaahCms.php. Then the parts that are specific to this platform. Entities/ suggests a domain model that is separated from the persistence models, and Libraries/, Loaders/ and Observers/ are the extension points. Mail/, Notifications/ and Jobs/ are scaffolding for the application features a CMS needs, and Traits/ holds the reusable behaviour that the generated code depends on. There is a Resources/ directory, which in Laravel holds the translation files and the views, and a Tests/ directory. There is also a Vue/ directory at the root, which is the admin frontend, and a Resources/assets/backend/vaahone/images directory referenced by the logo in the documentation, which suggests the admin interface has a backend/assets split. The configuration is vaah-config.json and the frontend build is tracked by mix-manifest.json, so the admin assets are built with Laravel Mix rather than Vite, which is the older of the two Laravel bundlers and is a sign of the age of the base application this platform grew from. Two other files are worth naming. There is a changelog-template.hbs, a Handlebars template for generating changelog entries, which means the changelog is generated from commits rather than written by hand. And there is INSTRUCTIONS.md at the root, which is a file for instructions to an automated agent working in the repository, following the convention that has become common in these projects. There is also a CHANGELOG.md, a .github directory, a .gitkeep, and a .gitignore. The LICENSE is MIT, and the documentation links to a separate license file for the full text. ## What it is likely to be good at, and where the trade-offs sit The features of the design suggest a particular kind of project. The strongest case is a Laravel application with substantial content that also needs an admin interface, where the content is not the whole product. A team that has been running a WordPress site next to a Laravel application, or embedding a CMS into an existing Laravel codebase, recognises the problem immediately. The headless API plus the module isolation means the content model can grow without the application logic being rewritten to accommodate it. The module and theme split also fits an agency, which is what the maintainers are. An agency building several Laravel applications can standardise on a platform and then write per-project modules, and the option to ship a Blade-only module means a simple project does not need a frontend build pipeline at all. The trade-offs are visible in the same description. A platform that supports HMVC, modules, themes, headless APIs, facades, a Vue admin frontend and Blade fallback is a lot of abstraction, and the cost is that you have to learn its conventions rather than plain Laravel. The HMVC pattern in particular is not what a Laravel developer expects by default, since Laravel's own convention is a flat application directory. The other trade-off is the version line. The 2.x branch is moving quickly with patch releases, which is healthy for a platform in active use and means the APIs are still shifting. The last push was on 2026-04-09 and the newest tagged release is v2.3.4 from 2025-11-04, so there is a gap between the two, and the documentation site is versioned by major release, which is the place to check what changed. The bundled scope is also a consideration. Mail, notifications, jobs, observers, entities, facades and loaders all ship in the package, whether or not a given project uses them. For a platform that aims to be a starting point rather than a library, that is the correct trade, and for anyone wanting only the CMS it means more to understand than a focused package would give. ## Conclusion Adopt VaahCMS if you build Laravel applications that need content management without the CMS fighting your application code, since the headless API and the module isolation are the reason it exists. Skip it if you want a small site with a page builder, since this is an application platform rather than a site builder, and if you need a stable long-term release channel, since the 2.x line is a minor-version stream with frequent patch releases. Verify first which parts you actually need, because the repository bundles a CMS, a Vue admin frontend, facades, notifications and job scaffolding, and that you read the documentation site for the version you are on, since the docs live on a separate versioned site. ## FAQ ### What is VaahCMS and what stack is it built on? It is an open-source web application development platform shipped with a headless content management system, built with Laravel, Vue, Pinia and PrimeVue, and it follows the Hierarchical Model View Controller architectural pattern supporting multiple Modules and Themes. ### How do I install VaahCMS and what does the headless part give me? The Quick Start is a single command, `npx vaah cms:install`. The headless CMS ships with a built in API, so you can plug and play with any frontend framework like Nuxt or Next, and the CMS Module is inspired from the simplicity of WordPress. ### What are the modules and themes in VaahCMS and how flexible are they? Each module and theme can be set up with just Blade files support, or can have its own frontend JavaScript library such as Vue or React, so an isolated Vue or React app per module and theme is possible. The documentation for the 2.x line lives on a separate versioned site at docs.vaah.dev/vaahcms-2/, and the project asks for pull requests against a separate vaah-docs repository. ## Sources - [License: MIT](https://github.com/webreinvent/vaahcms/blob/2.x/LICENSE) - [Project website](https://vaah.dev/cms) - [README](https://github.com/webreinvent/vaahcms/blob/2.x/README.md) - [Releases](https://github.com/webreinvent/vaahcms/releases) - [webreinvent/vaahcms on GitHub](https://github.com/webreinvent/vaahcms) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webreinvent-vaahcms