django CMS

Last reviewed Aug 26, 2026 · 769 words

If nobody on your team writes Python, stop here and install WordPress; django CMS will cost you weeks and give you nothing WordPress would not. If your team does write Django, keep reading, because django CMS is 1 of 2 serious choices for a content site inside a Django project, it has the best multilingual page handling of any open-source CMS I have run, and it gives editors an in-place editing experience that most developers assume needs a paid product.

It is a Django application, not an appliance

There is no image you run and log into. django CMS is a set of Django apps you install into a project you own: your settings.py, your urls.py, your templates, your migrations, your collectstatic, your gunicorn. The project publishes a quickstart repository with a Docker Compose file that brings up a demo site in about 10 minutes, and that is exactly what it is, a starting point for a developer. Production is the same work as any Django deployment plus the CMS-specific pieces below. The catalogue's Hard rating and 1 GB of RAM are fair; the RAM is for gunicorn workers and Postgres, and the difficulty is that every decision is yours.

What editors actually get

Log in and visit any page and a toolbar appears at the top. Templates declare placeholders; editors drop plugins into them: text, images, links, columns, embedded forms, and whatever your developers write, since a plugin is a small Django model with a template. A structure mode shows the page as a tree of plugins you can drag between placeholders. The page tree lives in the admin, with drafts, publishing, and per-page permissions, and the versioning app keeps a history you can roll back. The editing model is "lay out this page" rather than "fill in this form", which is what non-technical editors tend to prefer and what makes django CMS feel closer to a page builder than a database front-end.

Multilingual is the real differentiator

Every page has content per language, with a fallback chain you define, a language chooser, and URLs that carry the language prefix. Editors translate page by page and plugin by plugin, so a marketing team can have the French site 60% done while the English one is live. This is where the "enterprise" in the tagline is earned: the same feature on WordPress means WPML or Polylang and a page structure that was never designed for it, and on Wagtail it means adding wagtail-localize. On django CMS it is core and it has been for over a decade.

The stack you will own

services:
  web:
    build: .
    command: gunicorn myproject.wsgi:application --bind 0.0.0.0:8000 --workers 3
    env_file: .env
    volumes:
      - media:/app/media
    depends_on: [db]
    restart: unless-stopped
  db:
    image: postgres:16
    env_file: .env
    volumes:
      - pg:/var/lib/postgresql/data
    restart: unless-stopped
volumes:
  media:
  pg:

Caddy in front terminating TLS and serving /static/ from the collectstatic output; the media volume holds everything editors upload and is the thing you must back up alongside a nightly pg_dump. Postgres from day 1, not SQLite, for the reasons in Postgres for everything. Pin django-cms and Django versions in your requirements, read both changelogs before upgrading, and rehearse the migration on a copy of production; the CMS packages have historically shipped larger structural changes than typical Django apps.

django CMS against Wagtail and WordPress

Wagtail is the other Python answer, and today it is the more popular one. Its model is different: editors fill structured fields (StreamField) in the admin, and templates render them, which suits content that is data first, a magazine or a documentation site. django CMS suits content that is layout first, a corporate site with landing pages that marketing wants to rearrange without a ticket. Both scale, both are maintained, and a team can pick badly by choosing on popularity alone. WordPress wins on everything that is not "we have Django developers and want to keep it in Django": themes, plugins, hosting options, and finding someone to maintain it in 3 years. The full set of options is on the CMS category page.

What I'd do

A Django shop building a multilingual company site with editors who want to move things around on the page: django CMS, Postgres, gunicorn, Caddy, the media volume in the backup rotation, and versions pinned. The same shop building a content-heavy site with a defined structure: Wagtail. Anyone without a Django developer on payroll: WordPress, and no regrets.