# Statamic: a flat-first, Git powered CMS for Laravel

> Statamic is a Laravel CMS that stores content in flat files and treats Git as the version history, and this repository holds the skeleton of a fresh Statamic project rather than the CMS package itself, which lives in statamic/cms. It suits a team that wants editors in a friendly admin panel without giving up a diffable, reviewable content repository, and it does not suit a project that needs a hosted multi tenant admin.

**statamic/statamic** — Statamic: The New Site/App Package

- Repository: https://github.com/statamic/statamic
- Website: https://statamic.com
- Stars: 835 · Forks: 96
- Language: PHP
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/statamic-statamic

## This repository is a project skeleton, not the CMS

The most important line in the README is a note, and it changes what this repository is.

It says that this repository contains the code for a fresh Statamic project that is installed via the Statamic CLI tool, and that the code for the Statamic Composer package itself can be found at the Statamic core package repository.

So the split is between the engine and the empty application. The engine, the CMS itself, the control panel, the add-ons and the whole API surface live in statamic/cms and are installed through Composer. What is here is the scaffolding that a new site starts from: the app directory with the application code, the bootstrap directory, the config directory, the content directory, the database directory, the lang directory for translations, the public directory for the web root, the resources directory for views and assets, the routes directory, the storage directory, a users directory, a tests directory, an artisan file, a please file, a composer.json, a package.json, a vite.config.js and a phpunit.xml.

That is a Laravel application skeleton with the Statamic conventions already in place, and it is why the file list looks so familiar. Anyone who has scaffolded a Laravel app will recognise the shape immediately, which is deliberate: the tool the README points you at, the Statamic CLI, produces a project that looks like a Laravel project because it is one.

The practical consequence for an evaluation is that reading this repository tells you very little about the CMS. The CMS is in another repository, the documentation is at statamic.dev, and the interesting questions about the control panel and the content model have to be answered there.

## Flat files and Git are the design, not a feature bolted on

Statamic is described as the flat-first, Laravel and Git powered CMS designed for building beautiful, easy to manage websites.

Flat-first is the load-bearing phrase. Instead of rows in a database, content lives in files in the content directory of the repository, and because it is a repository, Git is the version history. That single decision changes how a team works.

A content change becomes a pull request. It can be reviewed, it can be reverted with git, and it can be branched, which means a campaign page or a product update can be drafted on a branch and merged on a schedule. In a database backed CMS, the same operation requires either a content API with its own versioning story or an export and import process, and the version history is usually something the CMS provides rather than something your tools already know about.

The cost of the model is that it suits one repository per site rather than one admin panel for many sites. If you run a multi tenant platform where dozens of sites are edited by one team in one place, flat files per site means a different working pattern, and that is a structural difference rather than a configuration choice.

The audience for the flat model is the team that already works in Git, or the agency handing a site over to a client who wants a repository they can keep. The audience for the control panel is the editor who never opens a terminal, and Statamic is trying to serve both at once, which is the whole bet of the project.

The topics attached to the repository include cms, laravel, laravel-cms, laravel-package, composer-package, tailwindcss and vuejs, which is a fair map of the stack: PHP and Laravel underneath, a modern front end build on top.

## The Stache watcher and the static caching strategy

The environment file in this repository exposes the Statamic specific settings, and two of them explain how the CMS behaves at runtime.

```bash
STATAMIC_STACHE_WATCHER=auto
STATAMIC_STATIC_CACHING_STRATEGY=null
```

The Stache is Statamic's content layer, and the watcher is what keeps the in memory view of your flat files in step with what is on disk. The value here is auto, which means the watcher decides for itself whether to run, and the two plausible choices are to watch the filesystem for changes or to rebuild the cache when content is saved through the control panel. The auto setting is the safe default, and it is also the setting that will differ most between your laptop and a production server, where filesystem watching is often unavailable or restricted.

The static caching strategy is the other one, and null means no static caching is configured. This is the switch that decides how aggressively Statamic pre-renders content into static HTML. Left at null, pages are rendered on request. Configured, the system writes pages to disk and serves them as files, which is a meaningful change in how a site behaves, because some dynamic features stop being available and the rebuild process becomes part of your deployment.

That is a design decision worth making deliberately rather than by leaving a default in place. A static site is fast and cheap to host, and it is also a different kind of site to build, and the .env.example shows the switch without any commentary on when to turn it on.

The other Statamic flags in the file cover the feature set, and they are covered in more detail below.

## The environment file is the clearest picture of the edition split

The .env.example in this repository is worth reading in full, because it is the most compact map of what a Statamic project is and is not.

```bash
STATAMIC_LICENSE_KEY=
STATAMIC_PRO_ENABLED=false
STATAMIC_TWO_FACTOR_ENABLED=true
STATAMIC_REVISIONS_ENABLED=false
STATAMIC_GRAPHQL_ENABLED=false
STATAMIC_API_ENABLED=false
STATAMIC_GIT_ENABLED=false
```

The pattern is legible. Two factor authentication is on by default, which tells you that the control panel is expected to be reachable by real users and that securing it is the default rather than an add on. Revisions, GraphQL, the API and Git integration are all off by default, and each of them corresponds to a feature that Statamic Pro provides.

The Git flag is the interesting one for anyone adopting Statamic for its flat file model. Git integration is not on by default, which suggests that the Git features are an add on rather than part of the core, and that using the system with plain Git and your own branching, without the integration, is a supported path. Given that the core premise is that content lives in files, the ability to work without the integration is exactly what makes the model usable for a team that already has strong Git practices.

The rest of the file is standard Laravel. The default database connection is sqlite, sessions are file based, the queue connection is sync, the cache store is file, mail goes to the log driver, and there is a block of AWS variables for an S3 bucket. The S3 variables alongside the local filesystem default are the clue to the deployment model: content in the repository, and the media and assets somewhere else, most likely in object storage, which is the standard way to run this in production without committing binaries.

## The front end build is Vite 8 and Tailwind 4

The package.json in this repository is small, and it describes a modern Laravel front end stack.

```json
    "scripts": {
        "build": "vite build",
        "dev": "vite",
        "watch": "vite"
    },
    "devDependencies": {
        "@tailwindcss/vite": "^4.0.6",
        "laravel-vite-plugin": "^3.1",
        "tailwindcss": "^4.0.6",
        "vite": "^8.0.0"
    },
```

The build tool is Vite, wired into Laravel through the Laravel Vite plugin, with Tailwind CSS at version 4 and its dedicated Vite plugin. The three scripts are the standard ones: build for production, dev for a development server, and watch for rebuilding on change. The concurrently package is also present, which is the standard way to run the Vite dev server and the PHP dev server at the same time from one command.

There is one unusual entry in the optional dependencies: @laravel/multiplex at version 0.4.1, marked optional. Being in optionalDependencies rather than devDependencies means the build does not break if it cannot be installed, which is a sensible arrangement for a package that is not needed in every project.

The front end choice matters for a CMS evaluation because the control panel and the templates are separate worlds. Tailwind in the templates is a choice the site author makes, and the presence of vuejs in the topic tags suggests the admin panel side of the project uses Vue. Neither is a constraint on the content model, but both tell you what a developer joining the project will be expected to know.

For the tests, the repository has a phpunit.xml and a tests directory, and there is a .styleci.yml and an .editorconfig for style, so the project is set up for continuous integration from the start.

## Support is split between a paid tier and the community channels

The support section sets out a two tier arrangement that is worth understanding before a team commits.

Official developer support is provided on Statamic Pro projects. Community-driven support is available via GitHub Discussions and in Discord.

So there is a paid product inside an open source project, and the distinction shows up in the environment file, where STATAMIC_PRO_ENABLED defaults to false and STATAMIC_LICENSE_KEY is empty. A Pro key is what switches the paid features on.

The boundary between the editions is visible in the same file. GraphQL, the API, revisions and Git integration are all off by default, and each maps to a feature the README associates with the Pro tier. Two factor authentication, by contrast, is on by default, which means the security baseline of the control panel is not a paid extra.

For a team, that framing turns into a procurement question. The open source parts are what you get without a licence key, and the README says community support is available through GitHub Discussions and Discord, which is a real answer to a question about where to ask when something is unclear. But a team that wants a support contract is buying into Pro, and the decision should be made with the feature list in front of you rather than discovered later.

There is also a separate tool, the Statamic Migrator, linked from the important links section. Its existence says something useful about who the project is for: teams with an existing site who want to move to Statamic, which is a common reason a CMS evaluation starts in the first place.

## Licence, versions and what to check before you start

Three practical things to settle before writing a line of code.

The first is the licence. The repository is recorded as having a custom licence that GitHub cannot classify, with a pointer to the LICENSE file, and the README does not restate the terms anywhere. For a project skeleton that a site owner will copy and own, that is the document to read, and if you are building a site for a client, the terms matter to both of you.

The second is the version line. The default branch here is 6.x, and the recent releases are v6.5.2 on 2026-10-08, v6.5.1 on 2026-09-08 and v6.5.0 on 2026-08-06, with the last push to the repository on 2026-10-08. So the 6.x line is in steady maintenance with patch releases roughly monthly, and this skeleton tracks it.

The third is the route in. The README says to install a fresh Statamic project via the Statamic CLI tool, and to find the Composer package in the core repository. Creating a project by copying this tree is possible, since the .env.example is deliberately incomplete so it can be copied, but the supported path is the CLI, and the CLI is what will keep a new project aligned with the current conventions.

One last practical point about the shape of the skeleton itself. The users directory, the content directory and the config directory are part of the project, and a file based CMS means the content directory is where the site lives. Combined with the Git integration flag being off by default, the picture is of a project where the repository is the CMS storage, and where the admin panel is an optional way to edit what is otherwise plain files. That is the decision to make, and everything else in this repository follows from it.

## Conclusion

Statamic suits a Laravel team that wants a polished editing experience for content while keeping every piece of content as a file in Git, because that combination gives editors a normal CMS and gives the engineering team a code review on every content change. It does not suit a multi tenant SaaS that needs a single admin for many sites from one login, since the model here is one repository per site, and it does not suit a team that cannot operate a Laravel application itself. Before you adopt it, read the .env.example in this repository line by line, because the feature flags there tell you which parts of Statamic are core and which belong to Pro, install the project with the Statamic CLI rather than by copying this tree, and note that the last push to the repository was on 2026-10-08 with the newest release tag v6.5.2 from the same day while the repository licence is recorded as one GitHub cannot classify.

## FAQ

### What is Statamic?

Statamic is described as the flat-first, Laravel and Git powered CMS designed for building beautiful, easy to manage websites. The content lives in files in the repository rather than in database rows, with Git providing the version history.

### Does this repository contain the Statamic CMS code?

No. The README states that this repository contains the code for a fresh Statamic project installed via the Statamic CLI tool, and that the Statamic Composer package itself is in the core package repository at statamic/cms.

### Which Statamic features are Pro only?

The .env.example ships with STATAMIC_PRO_ENABLED=false and an empty STATAMIC_LICENSE_KEY, with GraphQL, the API, revisions and Git integration all disabled by default, which maps them to the paid tier. Two factor authentication is enabled by default, so the control panel security baseline is not a paid extra.

### What front end tooling does a Statamic project use?

The package.json declares Vite with the Laravel Vite plugin, Tailwind CSS 4 with its Vite plugin, and concurrently, with build, dev and watch scripts. The optional dependencies include @laravel/multiplex at version 0.4.1.

### What database and storage does a new Statamic project use by default?

The .env.example sets DB_CONNECTION=sqlite, SESSION_DRIVER=file, QUEUE_CONNECTION=sync and CACHE_STORE=file for local development, and includes AWS bucket variables for storing media and assets in object storage in production.

## Sources

- [Issues](https://github.com/statamic/statamic/issues)
- [Project website](https://statamic.com)
- [README](https://github.com/statamic/statamic/blob/6.x/README.md)
- [Releases](https://github.com/statamic/statamic/releases)
- [statamic/statamic on GitHub](https://github.com/statamic/statamic)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/statamic-statamic