Statamic CMS: the core Laravel package behind a working site

The repo is the package, statamic/statamic is the site

Cloning statamic/cms does not hand you a website. A note near the top says this repository holds the code for the core Statamic Composer package, to be installed into an existing Laravel application, and that a separate application repository holds a Laravel application preconfigured with Statamic, the one used when the Statamic CLI creates a new project. Two artifacts, two workflows: a team with an existing Laravel codebase takes this package and wires it into its own routes, config and front end, while a team starting from nothing takes the preconfigured application instead. That split also fixes the boundary of this article. Content types, users, permissions, and how a published page gets edited in a browser are not described here, and the README sends readers to statamic.dev for all of it.

Two Vite configs, and a dev script that wipes dist first

The JavaScript half of the package is built with Vite, and it runs two pipelines rather than one. The dev and build scripts use the root vite.config.js, while frontend-dev and frontend-build pass -c vite-frontend.config.js, a second configuration for the assets a site itself consumes. The dev script is blunt about stale state: it runs `rm -rf resources/dist/build && rm -rf resources/dist-dev/build` before Vite starts, so an earlier build cannot survive into the next one. SVG assets get their own pass through `svgo -f ./resources/svg/ -r`, governed by svgo.config.js at the root.

Vue on Inertia, Tiptap by extension, one beta drag handle

The control panel is a Vue application wired to Laravel through Inertia: package.json pins `@inertiajs/vue3` at ^2.1.11. Content fields are assembled from Tiptap ^3.28.0 and its extension packages, so the editor is a set of parts you extend rather than one bundled editor. `@tiptap/extension-code-block-lowlight` covers highlighted code blocks, `@tiptap/extension-character-count` covers length limits. Structural editing comes from `@he-tree/vue` ^2.10.5 and reordering from `@shopify/draggable`, pinned at ^1.0.0-beta.12. That last one is a beta release sitting inside the admin bundle, which is a reason to test reordering after an upgrade instead of assuming it still works. Dates go through `@internationalized/date` ^3.7.0, markdown rendering through `@davidenke/marked-text-renderer` ^3.0.0, and passkey sign-in through `@simplewebauthn/browser` ^13.2.2.

First run: the npm scripts this repository actually writes down

Installation starts somewhere else. The README gives no Composer command for this package. It points new projects at the preconfigured Laravel application in statamic/statamic and at the Statamic CLI, and everything else at statamic.dev. Working inside the package itself is a Node job, and package.json is where the commands are written down:

"dev": "rm -rf resources/dist/build && rm -rf resources/dist-dev/build && vite",
"build": "vite build",
"frontend-dev": "vite -c vite-frontend.config.js",
"frontend-build": "vite build -c vite-frontend.config.js",
"storybook": "storybook dev -p 6006 --no-open"

Install the pinned dependencies against the checked-in package-lock.json, then build the site-facing bundle:

npm install
npm run frontend-build

Storybook serves component work on port 6006 and is told not to open a browser, which the --no-open flag in that script handles; the docs variant of the same command is storybook-docs. Type definitions come from the `types` script, which changes into packages/cms and runs that package's own npm script. The pinned versions themselves are here:

"@inertiajs/vue3": "^2.1.11",
"@tiptap/core": "^3.28.0",
"@shopify/draggable": "^1.0.0-beta.12",
"@simplewebauthn/browser": "^13.2.2"

PHPUnit on one side, vitest on the other

Testing runs on two stacks, and neither is a single command. The PHP side sits on PHPUnit with a root phpunit.dist.xml, a testbench.yaml for the Testbench harness Laravel packages run under, and a phpunit.bat wrapper for Windows. Static analysis is phpstan.dist.neon with its own .phpstan/ directory, and pint.json holds the code style rules. The JavaScript side is vitest, exposed as `npm test`, which runs `vitest run`; test-watch reuses it with `--watch --notify` so a failing run can notify the desktop. knip.config.ts exists to find unused exports and tsconfig.json holds the compiler settings. The cost lands on whoever contributes: a working Composer install and a working Node install, plus a PHP test command that package.json does not define and that you have to take from CONTRIBUTING.md or the docs.

No PHP version, no Laravel version, no upgrade notes

The README runs to about 240 words and never names a PHP version, a Laravel version, an upgrade procedure, or a rollback path. It does not say what the config/, routes/, lang/ or packages/ directories are for, and it gives no install command for the package itself. The license identifier comes back as NOASSERTION while LICENSE.md sits at the root, so the terms live in that file rather than in a field the hosting site displays. What you can measure is cadence. The default branch is 6.x, the last push was on 2026-11-01, v6.39.0 shipped on 2026-10-29, v6.38.0 on 2026-10-23, and v5.74.7 on 2026-10-22. Read that as minor releases about a week apart, and read the branch name as a sign that crossing a major version is a migration rather than a version bump. CHANGELOG.md at the root is where you look between tags.

Support sits behind Statamic Pro, migration sits in another repo

Support is tiered, and the README is plain about it: official developer support is provided on Statamic Pro projects, with the pricing page linked, while community support lives on GitHub Discussions and Discord. A team without a Pro licence has no official channel, which matters most when the outage is an editor who cannot publish. Contributors are asked to review the contribution guide in CONTRIBUTING.md before opening issues or sending pull requests, and the code of conduct lives in the repository wiki rather than in a file at the root. The link list also points at a separate Statamic Migrator repository, so importing content from another CMS is not part of this package. That is where the difference from WordPress becomes practical: WordPress keeps content in database rows behind its own admin screens, while this package puts the editor inside the Laravel and Vue application your team already maintains.

Editorial conclusion

Adopt statamic/cms when your team already ships Laravel and wants the CMS to live inside that codebase rather than beside it. Skip it if you need an official support channel without a Pro licence. Before committing, check the PHP and Laravel version matrix on statamic.dev against your own app, then read LICENSE.md, because the license field on this repository is unset.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. statamic/cms on GitHub