Concrete CMS: a PHP CMS where the version branches are the architecture

The repository is a fork point, not a single version

The README is short, and the most useful thing in it is the Legacy section. This repository is for Concrete CMS 9.0 and later. Earlier versions live elsewhere: concrete5 8.x sits on the 8.5.x branch, concrete5 5.7.x on the 5.7.x branch, and concrete5 5.6 and earlier moved to a separate concrete5-legacy repository.

The README explains why the naming is confusing, noting that Concrete CMS used to be called concrete5 and that this hopefully explains the name of various GitHub repositories and projects. That is a small piece of history, but it tells you something real about the project: the same repository accumulates several incompatible generations, each pinned to a branch.

For an adopter this has a concrete consequence. You do not upgrade Concrete CMS the way you upgrade a Composer library. You move from branch to branch, or you take a release and apply it, and the old branch stays alive so that sites built on 8.x have somewhere to go. The default branch here is 9.5.x, and the contributor guide link in the README points at the develop branch, which tells you that day to day work happens elsewhere and 9.5.x is the maintained release line.

The releases follow that line: 9.5.3 on 2026-09-01, 9.5.4 on 2026-09-08 and 9.5.5 on 2026-10-06.

Installation is a clone and a Composer install

The installation section of the README has two steps. The first is to clone the repository:

        git clone https://github.com/concretecms/concretecms.git
        cd concretecms/

The second is to use Composer to install the third party dependencies:

        composer install

That is the entire documented procedure, and the brevity is worth reading carefully. A clone of the repository is not an installed site; the third party dependencies come from the lock file, and the application code lives in the repository rather than in a vendor directory.

For anything beyond a quick look, INSTALL.md in the repository root is the file to read next. The README does not summarise it, does not list PHP version requirements, does not name a web server requirement, and does not describe the database setup. The composer.json and composer.lock are at the root as well, so the dependency set and its pinned versions are inspectable before you install anything.

The robots.txt file at the root and the index.php entry point are the other two root files that tell you about the deployment shape: a PHP application served from the repository checkout, with the vendor directory added by Composer.

application/, concrete/, packages/ and updates/ are four different things

The top level of the repository is where the architecture is visible, and the directory names carry most of the meaning.

The concrete/ directory is the CMS itself, the framework code that ships with every install. The application/ directory is where the site you build lives, and it is the part you are expected to edit and back up. The packages/ directory holds packages, which is the extension mechanism for adding functionality beyond the core. The updates/ directory is the mechanism by which the system moves between versions at runtime, and it is the piece that makes the branch model above work in practice, because an existing site applies update steps rather than being rebuilt from a new clone.

The build/ directory sits alongside them, holding build related files, and tests/ with phpunit.xml at the root holds the test suite.

Two other root files are worth noting. CHANGELOG.md records what changed, and LICENSE.TXT holds the MIT licence terms. There is also a .php-cs-fixer.dist.php, which tells you the project uses PHP CS Fixer and ships a shared configuration so that contributions format consistently.

Four CI systems and two agent instruction files

The badges at the top of the README show two GitHub Actions workflows: a build status badge for the phpunit workflow and a badge for composer-audit, both tied to the 9.5.x branch. A Composer audit workflow in CI means dependency advisories are checked on the release branch rather than only at install time on a developer's machine.

But GitHub Actions is not the only automation present. The top level also carries .gitlab-ci.yml for GitLab CI, .scrutinizer.yml for Scrutinizer, .gitpod.yml and .gitpod.Dockerfile for a Gitpod development environment, and .coderabbit.yaml for the CodeRabbit review bot. So the project runs several overlapping quality services against the same codebase.

That is a lot of configuration for one repository, and it has a practical effect: contributor setup is expected to work through a hosted environment, and the same checks will fire whether or not the code was developed in that environment. It also means build definitions are spread across formats, which is one more thing to keep in mind when you fork the project for your own infrastructure.

The AGENTS.md and CLAUDE.md files at the root are instructions for coding agents, and CLAUDE.md is a common convention for giving an assistant repository context. Their presence signals that the project expects a large share of contributions to be prepared with automated tooling in the loop.

Documentation lives on its own site and is edited in the browser

The README points documentation to documentation.concretecms.org rather than keeping it in the repository, and it explains how it is maintained: log in to the documentation site with your community.concretecms.com account and edit. Contributions are welcomed, and the phrasing invites corrections as well as new material.

That is a deliberate model. Documentation written in the same repository as the code tends to drift behind the code and gets reviewed by the same people who wrote it. A separate site with community accounts opens the review pool to people who use the CMS without writing PHP.

It also means the documentation is not versioned with the code in the way you might expect, so a page describing a feature can describe the behaviour of a different release line than the branch you have checked out. When you are diagnosing a problem on 9.5.x, the practical move is to look for version notes on the documentation site as well as in CHANGELOG.md.

The community channel the README lists is the forums at forums.concretecms.org, and the contributor guide on the develop branch is where a new contributor is pointed for the process of getting a change accepted.

What the project does not tell you

The gaps in this README are real and worth naming before you commit to the project.

There is no stated PHP version requirement, no database requirement, no web server guidance and no deployment recipe. There is also no feature list, no screenshot of the editing interface, and no description of the block, page and theme model that a Concrete CMS site is built from. Nothing in the README describes the extension API, the permissions model, or the update mechanism in any detail beyond the existence of the updates/ directory.

That is not necessarily a criticism of the project, since the documentation site exists and INSTALL.md is in the repository, but it does mean that judging Concrete CMS from the README alone is not possible. Anyone evaluating it has to read the documentation site and the install guide, and to inspect composer.json for the actual dependency and version constraints.

The other structural point is the one about maturity of the ecosystem around the code. This is a fork of a long-running open source project with a name change, several generations of code in one repository, a community documentation site with accounts, a package directory and a runtime update system. That is a lot of institutional machinery, and it is what you are buying when you choose this CMS over building a thin application layer over a framework.

The last push was on 2026-10-20, two weeks after the 9.5.5 release on 2026-10-06, and the repository is not archived, so work on the release line continues.

Editorial conclusion

Concrete CMS fits teams that want a self-hosted PHP content management system with a vendor community behind it, and it is a poor fit for a project that wants a headless API, a modern framework stack, or a deployment story with one command. Before adopting it, read INSTALL.md and check the composer.json requirements against your PHP version, confirm that the 9.5.x branch is the one you want to track rather than the develop branch referenced in the contributor guide, and plan your upgrade path around the fact that old releases live on their own branches, with 9.5.5 published on 2026-10-06.

Frequently asked questions

Official sources

1. concretecms/concretecms on GitHub
2. License: MIT
3. Project website
4. README
5. Releases