Backdrop CMS

Last reviewed Sep 13, 2026 · 858 words

Backdrop CMS exists for one group of people: organisations that built on Drupal 7, faced the January 2025 end of life, and did not have the budget for the near-rewrite that moving to Drupal 10 or 11 demands. For them it is the right answer, arguably the only reasonable one. For everyone else, a new site in 2026 should start on WordPress if it needs an ecosystem or on a flat-file CMS if it does not, and Backdrop's 1,045 stars and smaller module catalogue are the honest signals of that.

A fork that kept the Drupal 7 shape on purpose

Backdrop forked from Drupal 7 in 2015, when Drupal 8 rebuilt the project on Symfony and broke every contributed module. Backdrop kept the D7 API, the hook system, the theme layer and the admin concepts, then added the things D7 site builders had been asking for: configuration management, a layout system for placing blocks on page templates, a responsive admin theme, and a built-in rich-text editor. A Drupal 7 developer can be productive in Backdrop in an afternoon, and there is an official upgrade path that migrates a D7 database in place.

That backward compatibility is the project's core promise: point releases every few months, no breaking API changes within the 1.x line, and a stated commitment to a slow, predictable cadence. Small non-profits and municipal sites that update once a quarter are the target, and it fits them.

It runs where Drupal 10 does not

Drupal 10 wants Composer, PHP 8.1+, and a deployment pipeline. Backdrop wants PHP, MySQL or MariaDB, and a directory you can upload over SFTP if that is how your organisation works. The catalogue's 512 MB minimum is realistic; a small site with a few thousand pages runs on 1 GB shared hosting with room for caching. In Docker there is an official image:

services:
  backdrop:
    image: backdrop:latest
    ports:
      - "8080:80"
    environment:
      - BACKDROP_DB_HOST=db
      - BACKDROP_DB_USER=backdrop
      - BACKDROP_DB_PASSWORD=backdroppass
      - BACKDROP_DB_NAME=backdrop
    volumes:
      - ./files:/var/www/html/files
    depends_on: [db]
    restart: unless-stopped

  db:
    image: mariadb:11
    environment:
      - MARIADB_DATABASE=backdrop
      - MARIADB_USER=backdrop
      - MARIADB_PASSWORD=backdroppass
      - MARIADB_ROOT_PASSWORD=rootpass
    volumes:
      - ./db:/var/lib/mysql

Open port 8080 and the installer walks you through site name and admin account. Everything the site owns lives in files/ and the database; back up both, and put a reverse proxy with HTTPS in front before you invite editors.

Configuration in JSON is the feature Drupal 7 never had

Every setting, content type, view, layout and field definition in Backdrop is a JSON file in the active configuration directory under files/config_*/active. You can export the whole set from the admin UI or copy the directory, commit it to git, and import it on staging or production. That gives a small team a real dev-to-live workflow: build the content type locally, commit, deploy, import, done. Drupal 7 needed the Features module and a lot of patience to approximate this; Drupal 8+ has it but with a heavier toolchain. For a two-person web team, Backdrop's version is the most practical of the three.

The layout system is the other visible improvement. Instead of one page.tpl and a block-region grid, you define layouts (front page, section landing, article) and place blocks per layout with conditions, all through the UI. It makes the "different sidebar on the news section" request a five-minute job rather than a template edit.

The module gap is real and you should measure it

Backdrop's contributed module directory has a few hundred entries, most ported from D7 favourites: Views is in core, Pathauto, Metatag, Webform, Redirect, Token and the usual SEO and form suspects are available. What is missing is the long tail: the one integration module your D7 site relied on may not have been ported, and you will either port it yourself (usually a few hours, since the API is nearly identical) or replace the functionality. Audit your current module list against backdropcms.org before committing to a migration, and do it before the hosting bill renews.

Against WordPress, the gap is wider: WordPress has tens of thousands of plugins and a labour market of developers; Backdrop has a friendly, small community and a handful of agencies. If nobody on your team knows Drupal, that gap decides it. If you want something structured but tiny, Grav does flat-file content with no database at all, and the CMS category has the rest.

What I'd do

Running Drupal 7 today: migrate to Backdrop this quarter using the official upgrade path, audit modules first, put the config directory in git, and host it on the same 1 GB box you already have. Starting fresh with no Drupal history: choose WordPress for an editorial site with plugins and a budget for updates, Grav for a brochure site, and give Backdrop a look only if you specifically want Drupal's content modelling without Drupal's toolchain. It is a good, stable, deliberately unexciting piece of software, and its ideal user already knows who they are.