# Craft CMS: a self-hosted PHP CMS with a clean-slate content model

> Craft CMS is a self-hosted PHP application from craftcms/cms that stores content in MySQL or PostgreSQL and renders it through Twig or an auto-generated GraphQL API. It suits teams who want to define their own content structure rather than inherit one.

**craftcms/cms** — Build bespoke content experiences with Craft.

- Repository: https://github.com/craftcms/cms
- Website: https://craftcms.com
- Stars: 3,609 · Forks: 704
- Language: PHP
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/craftcms-cms

## What Craft CMS is for, and who ends up running it

Craft CMS describes itself as "a flexible, user-friendly CMS for creating custom digital experiences on the web and beyond." The operative phrase in the README is "a clean-slate approach to content modeling that doesn't make any assumptions about the content you need to manage." That is the whole pitch. Where most CMS products ship with posts, pages, categories and tags already wired together, Craft starts with nothing and asks you to declare the fields and the relationships yourself.

That makes it a poor fit for someone who wants a blog running in twenty minutes. It makes it a good fit for agencies and in-house teams whose content does not map onto a blog. If your data looks like a product catalogue with regional variants, a directory of practitioners with credentials, or a set of editorial collections that share fields but not templates, the clean-slate model saves you from fighting a schema someone else chose.

The repository is a PHP application, and the README is explicit that it is "self-hosted." There is no managed Craft Cloud implied by the repository itself. You supply the server, the PHP runtime and the database. That single fact shapes everything else: upgrade cadence, backup strategy and who gets paged when something breaks are all yours.

## Content modeling, Twig rendering and the GraphQL layer

The mechanism is straightforward once you accept the premise. You define sections, fields and entry types in the control panel, and Craft writes the corresponding tables into MySQL or PostgreSQL. Content storage is relational, not a document blob, which is why the README lists both database engines under Tech Specs.

Rendering happens in Twig. The README calls the templating system "fast and flexible" and links to the 5.x template documentation. A template queries entries and prints fields; there is no intermediate page-builder layer unless you install one.

For headless use, Craft generates a GraphQL API from your content model automatically. That is the part worth pausing on. Because the schema is derived from the fields you defined, adding a field changes the API surface without a separate schema file to maintain. It also means the API is only as tidy as your content model. A team that adds fields ad hoc will produce a sprawling GraphQL schema, and the README offers no guidance on governing that.

The extension framework is the other structural piece. The README points to a dedicated extend documentation section and a built-in Plugin Store. Plugins are the sanctioned way to add behaviour, and the framework is what plugin authors build against.

## Installing Craft CMS and rendering a first entry

The README sends you to the Installation page, which it summarises as "Jump right in with Composer." That is the supported path: Craft is distributed as a Composer package, not as a zip you unpack. The exact package name and version constraint live on that documentation page, and the README does not restate them, so there is no install command to copy from the repository.

After the project is created, the installer walks through database credentials and creates the first admin account. You need a database already running. The README names MySQL and PostgreSQL as the supported engines, and the Server Requirements page is where the minimum PHP version is stated.

Once the control panel is reachable, the first real task is defining a section and a field, then printing an entry. The 5.x template documentation linked from the README is where the query syntax lives; a template queries a section and loops over the entries it returns, printing each entry's title and field values.

What you should see is one heading per published entry in the section, with the body field rendered below it. If the loop prints nothing, the usual causes are that no entries are live yet or that the section handle in the template does not match the one you created.

If you plan to build the control panel assets from source, the repository has a Node side as well. package.json sets `"engines": { "node": ">=20" }` and defines `build`, `dev` and `serve` scripts, and .env.example documents the dev server variables:

```bash
DEV_SERVER_PUBLIC=http://localhost:8085/
DEV_SERVER_PORT=8085
DEV_SERVER_LOOPBACK=http://host.docker.internal:8085
```

Those three keys are the defaults for running webpack-dev-server from the host; the same file shows a commented block for running it inside a container on port 3000. This is only relevant if you are working on the CMS itself or on a plugin's front-end assets. A normal site build never touches it.

## Where Craft CMS stops being the right tool

The clean-slate model has a cost that the README does not advertise. Nothing is pre-built, so the first week of a project is schema design, not content entry. On a small marketing site with five pages, that overhead is pure loss and a flat-file or hosted builder will beat it on time to launch.

Self-hosting is the second constraint. The README states plainly that Craft is a self-hosted PHP application. That means you own patching, database migrations, file permissions and backups. If your team has no one who is comfortable with PHP deployment, the ongoing cost is real and it does not shrink over time.

The release history also matters for anyone on the older line. The default branch is 5.x, and the most recent releases listed are 5.11.3 and 5.11.2 from September 2026, alongside 4.18.9 from the same week. A 4.x release landing at the same time suggests the previous major is still being patched, but the repository does not state a support window or an end-of-life date. If you are planning a multi-year build on 4.x, that absence is something to resolve with the vendor rather than assume.

Finally, the licence. The repository carries a LICENSE.md file and GitHub reports the licence as NOASSERTION, meaning the classifier could not map it to a standard identifier. Craft's licensing has historically combined an open-source core with commercial terms for some uses. The repository does not spell this out, so read LICENSE.md directly before you commit to it.

## Craft CMS against WordPress and against a headless-only CMS

The comparison people actually make is Craft CMS versus WordPress, and the difference is architectural rather than cosmetic. WordPress arrives with a fixed content model: posts, pages, taxonomies, users, comments. You extend it with plugins and custom post types, but the core assumptions stay in place. Craft inverts that. The README's phrase about making "no assumptions about the content you need to manage" is the design decision, and it means a Craft project's schema is bespoke by default rather than by exception.

The practical consequence is plugin coverage. WordPress has a plugin for nearly any commodity feature. Craft's Plugin Store is described in the README as having "hundreds of free and commercial plugins," which is a different order of magnitude. If your requirement is an off-the-shelf booking system or a specific marketing integration, check the Plugin Store before you choose Craft, not after.

The other alternative is a headless-only CMS that ships an API and no control panel. Craft's GraphQL API is auto-generated from the content model, but Craft also has a full control panel for editors, and it stores content in a relational database you can query directly. A headless-only product usually gives you a hosted content API and no database access. If your editors need a real admin UI and your developers want SQL-level access to content, that combination is what separates Craft from a pure content API service.

## Maintenance, licensing and what to verify before you start

The repository is not archived, and the last push was on 2026-09-23, the same day as the most recent release window. Release cadence in the listed history is tight: 5.11.2 on 2026-09-17, 5.11.3 on 2026-09-18, and 4.18.9 on 2026-09-17. Frequent patch releases are good for security response and annoying for anyone who pins versions loosely. Plan to review the CHANGELOG.md before each upgrade rather than pulling the latest tag blindly.

Upgrade cost is dominated by two things. First, major-version moves: the repository maintains 4.x and 5.x in parallel, and the 5.x branch is the default, so a 4.x site is on a branch that will eventually need attention. Second, plugin compatibility. Craft's extension framework is deep, which means plugins reach into internals, and a major upgrade can break them. The repository gives you no compatibility matrix; the Plugin Store and each plugin's own release notes are where that lives.

On licensing, the only safe statement is procedural. LICENSE.md is in the repository root, and GitHub's classifier reports NOASSERTION, so the file does not match a recognised SPDX identifier. Read it, and if your use case is commercial or you plan to redistribute, get an answer from the vendor rather than inferring one from the repository metadata. Nothing here is legal advice.

The front-end toolchain is a smaller ongoing cost. package.json pins Node `>=20`, and the build runs through webpack with Prettier and Stylelint checks wired into lint-staged and Husky. That matters only if you are contributing to the CMS or building a plugin's assets, but it does mean the repository expects a modern Node runtime for that work.

## Conclusion

Adopt Craft CMS if you need a content model you define yourself and you are willing to run a PHP application with its own database. Skip it if you want a hosted site builder or a plugin ecosystem that covers every feature out of the box. Before committing, check the Server Requirements page for your PHP and database versions, read LICENSE.md for the licensing terms, and confirm the 4.18.x branch is still receiving releases if you cannot move to 5.x.

## FAQ

### What does Craft CMS do?

It is a self-hosted PHP content management system for building custom digital experiences. You define your own content model, render it with Twig templates, and can expose it through an auto-generated GraphQL API.

### Who owns Craft CMS?

The repository is craftcms/cms and the homepage is craftcms.com, which is where the README directs you for documentation, the Plugin Store and community links. The repository does not describe the corporate structure behind the project.

### Is Craft CMS a headless CMS?

It can be used headlessly. The README lists an auto-generated GraphQL API for building headless applications, alongside a control panel and a Twig templating system for conventional server-rendered sites.

### Is Craft CMS better than WordPress?

They differ in approach rather than quality. WordPress ships a fixed content model you extend, while Craft starts from a clean slate and expects you to define the model. Craft's README describes "hundreds" of plugins in its store, so check plugin coverage for your specific requirement before deciding.

## Sources

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

---

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