Statamic/cms: The Laravel CMS Composer Package, Reviewed for Adoption
The core Laravel CMS Composer package
At a glance
- What is it?
- Statamic's core package installs into an existing Laravel application and keeps content in files rather than a database. This review covers who it fits, how the flat-file layer works, and what the repository does not tell you.
- Who is it for?
- Adopt Statamic if you already run Laravel and want content stored as files that travel through Git alongside your code. Do not adopt it if you need a CMS you can hand to non-technical editors without a Laravel deployment pipeline behind them, or if you expect the cms repository to be a complete application.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem Statamic/cms solves, and who it is actually for
Most content management systems put content in a database and ask you to deploy code separately. Statamic inverts that. Its README describes it as "the flat-first, Laravel + Git powered CMS", which means entries, pages and configuration live as files that can be committed, diffed and rolled back with the same tools you already use for source code. The package you are looking at is not a website. The README is explicit: this repository "contains the code for the core Statamic Composer package, to be installed into an existing Laravel application." A separate application repository holds the preconfigured Laravel app that the Statamic CLI tool pulls when you create a new project.
That distinction decides the audience. If you have a Laravel application already and you want a control panel, a content API and a templating layer without adding a second runtime, this package is the unit you install. If you do not have a Laravel application, you start from the application repository instead and never touch this one directly. The topics list confirms the positioning: flat-file-cms, laravel-cms, headless, graphql, api-rest. Statamic is not trying to be one thing. It can render server-side templates and it can serve content to a separate front end.
How the flat-file layer and the Laravel binding fit together
The mechanism is a Composer package that registers itself with a Laravel application. Everything under src/, config/, routes/, resources/ and lang/ is shipped from this repository into your vendor directory, and the config files are publishable into your application's own config directory. The routes directory means the control panel and any API endpoints are registered by the package rather than written by you.
The repository layout shows a split between PHP and a front-end build. The package.json scripts run Vite for the control panel assets, with separate dev and build tasks, and a second Vite config named vite-frontend.config.js for front-end assets. There is a Storybook setup on port 6006 for component work, and a Vitest suite alongside the PHPUnit configuration. That is a lot of tooling for a CMS package, and it tells you the control panel is a Vue application compiled into resources/dist rather than a set of server-rendered Blade pages.
Content flows from files on disk into Laravel's container. Because the storage is flat, a Git commit is a content change, and a merge conflict is a content conflict. That is the trade you are making: version control for everything, and the operational habits of a code repository applied to editorial work.
Installing the package and rendering a first entry
The README does not give installation commands for this repository, because it expects you to arrive with a Laravel application already in place. What it does give is the pointer: the application repository is where the preconfigured Laravel app lives, and that is what the Statamic CLI tool creates. If you are starting fresh, follow that path rather than adding this package by hand.
If you do have a Laravel application and want to add the core package, the package is named statamic/cms and is installed through Composer. The README itself does not print the command, so treat the exact invocation as something to confirm against the package's Composer entry before you run it.
The repository ships the control panel routes, the configuration and the fieldtypes; it does not document the content authoring workflow. The README points to statamic.dev as the documentation site, and that is where the entry and template syntax is defined. Treat the docs site as the installation guide and this repository as the code you are depending on.
Where the flat-file design becomes the wrong choice
Flat files are excellent right up to the point where they are not. A content directory with thousands of entries becomes thousands of files on disk, and every request that needs to read a collection pays for filesystem access. Statamic caches aggressively to compensate, but the cache is now a thing you have to invalidate, and cache invalidation across multiple servers is a real operational problem.
There is a second limitation that matters more for teams. Editorial work in a Git-backed CMS produces commits. If your editors are not comfortable with branches and merges, and if your deployment pipeline does not tolerate content commits arriving between code releases, the Git model becomes friction rather than a feature. The repository gives no rollback command, no content migration tool and no conflict resolution workflow. The README is silent on all three. There is a separate Statamic Migrator repository linked from the README, which suggests migrations are handled outside this package, but the README does not describe what it does.
A third case: if you need a database-backed CMS with a mature plugin ecosystem and a hosting story that any agency can hand off, a flat-file CMS is the wrong shape. Statamic is a good fit for teams that already think in deployments and pull requests.
Statamic versus WordPress, and versus a pure headless CMS
The comparison people actually search for is Statamic versus WordPress, and the difference is architectural rather than cosmetic. WordPress stores content in MySQL and treats the database as the source of truth. Statamic stores content as files and treats the repository as the source of truth. That means Statamic content can be reviewed in a pull request and WordPress content cannot, and it means WordPress can run on shared hosting with a one-click installer while Statamic needs a Laravel-capable environment and a deploy step.
Against a pure headless CMS, the difference is the other direction. Statamic ships a control panel, routing, templating and a front-end build inside the same package, so you can render pages from the same application that stores the content. A headless CMS deliberately stops at the API and leaves rendering to whatever consumes it. Statamic supports both modes, which is convenient but also means the package carries the weight of both: the front-end dependencies in package.json include a full editor stack and a Vue application, and those are present whether or not you serve a headless API.
Licence, maintenance and what upgrades cost
The repository metadata reports the licence as NOASSERTION, which means GitHub could not map the LICENSE.md file to a recognised identifier. Read LICENSE.md yourself before you build a commercial product on it; this is a factual gap, not a legal opinion, and it is the single most important thing to resolve before adoption. The README also points to Statamic Pro pricing for official developer support, which implies that support is a paid tier and community support runs through GitHub Discussions and Discord.
The maintenance signal is strong. The default branch is 6.x, the repository is not archived, and the last push was on 2026-09-22. Releases are frequent and versioned: v6.33.0 on 2026-09-16, v6.32.0 on 2026-09-09, v6.31.0 on 2026-09-01. That cadence means minor upgrades arrive roughly weekly, and a Laravel package with weekly minor releases will occasionally require you to adjust configuration or recompile control panel assets. The package.json build scripts confirm that front-end assets are compiled, so an upgrade is not always a pure Composer operation.
What the repository does not tell you
Several things a buyer would want are absent from the documentation available here. There is no documented rollback procedure for content, no migration path described in this repository, and no statement about what happens to flat files when two editors save the same entry. The README covers learning resources, support channels and contribution guidelines, but it does not cover upgrade procedures between major versions.
The package.json is marked private and its name is statamic, which means it is the build manifest for this repository rather than a publishable npm package. Do not try to install it from npm. The PHP dependency is the one that matters, and it is installed through Composer.
Finally, the README points to an application repository for new projects. If you read only this repository and conclude that Statamic is a standalone download, you will be confused. It is a package, and the application is elsewhere.
Editorial conclusion
Adopt Statamic if you already run Laravel and want content stored as files that travel through Git alongside your code. Do not adopt it if you need a CMS you can hand to non-technical editors without a Laravel deployment pipeline behind them, or if you expect the cms repository to be a complete application. Before committing, check the LICENSE.md file because the repository metadata reports NOASSERTION rather than a recognised identifier, and confirm what the Statamic Pro pricing page covers for the support level you need.
Frequently asked questions
Is Statamic a headless CMS?
It can be. The repository topics include headless, graphql and api-rest, and the README describes Statamic as a CMS for building websites, so both server-rendered and API-driven front ends are supported by the same package.
Who uses Statamic?
The documentation does not name specific users or organisations. The README targets developers installing the core package into an existing Laravel application, and official support is offered on Statamic Pro projects.
What is the best Laravel-based CMS?
The available documentation only covers Statamic, which the README describes as a flat-first, Laravel and Git powered CMS installed as a Composer package. It makes no comparison against other Laravel CMS options.
Which CMS is better than WordPress?
The available documentation does not rank CMS products. It does establish that Statamic stores content as flat files tied to Git, while the README says nothing about how WordPress stores content.
what is statamic cms
The README describes Statamic as a flat-first, Laravel and Git powered CMS designed for building websites, distributed as a core Composer package installed into an existing Laravel application.
is statamic a headless cms
The repository topics list headless, graphql and api-rest alongside flat-file-cms, so Statamic can serve a separate front end. The README itself only describes the website-building use case.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/statamic-cms)