Mezzanine: a Django CMS that ships its features instead of assembling them

What Mezzanine solves for a Django team

A Django project gives you an ORM, a templating engine, caching and an admin. It does not give you a page tree, a blog, a forms builder, a search backend or a store. Teams that need those usually wire together several reusable Django apps and then own the glue between them. Mezzanine takes the other route: the README states that it provides most of its functionality by default rather than through a collection of reusable applications, and that this yields "a more integrated and efficient platform".

The audience is therefore narrow and specific. It is a developer who is comfortable in Django, wants hierarchical page navigation, scheduled publishing, in-line page editing and a WYSIWYG editor, and would rather extend an existing content model than assemble one. The README lists the ecommerce module Cartridge, a blog engine, tagging, user accounts with email verification, multi-lingual sites and per-page custom templates as part of the package.

The trade-off is visible in that same design choice. Because the functionality is bundled, upgrading means moving the whole platform, not one app at a time. The README does not document a rollback path for a Mezzanine upgrade, so plan for that gap before you commit a production site to it.

How the content model and admin fit together

Mezzanine is a Django application, so the mechanism is the one Django developers already know: models, migrations, templates and the admin. What Mezzanine adds is a content layer on top. Pages are hierarchical, which is what produces hierarchical page navigation, and the README lists drag-and-drop page ordering alongside it, so the tree order is editable from the admin rather than fixed in code.

Publishing is a state on the content, not a deploy. The README lists save as draft, preview on site and scheduled publishing, which means a page or post can exist in the database before it is publicly visible. Custom templates per page or blog post are also listed, so a single page can be rendered by a template you choose rather than by a global default. That is the extension point most teams will use first.

The README points to a documented API for custom content types, which is the intended way to add your own models to the page system rather than fighting it. Search is likewise described as a search engine and API rather than only a site search box. Third-party Django apps are expected to integrate, and the README calls that integration seamless, which is a claim worth testing against your own app list rather than taking on faith.

Installing Mezzanine and creating a first project

Mezzanine is distributed on PyPI, and the README's own badge links to the PyPI project page for the package name mezzanine. The README does not spell out a full installation sequence, and the repository files available here contain no installation commands, so there is no command sequence to reproduce accurately. What the README does give is the project page at mezzanine.jupo.org, which is where the documentation lives, and the PyPI project page linked from the version badge, which is where the package is published.

If you want to evaluate it before writing code, the two pages to read first are the content architecture documentation, which covers custom content types and page templates, and the search engine documentation, since those describe the two extension points most teams touch. The README also points to a set of sites built with Mezzanine, which is the closest thing to a worked example it offers.

Everything past that point depends on your own Django project layout. The README does not document a createdb step, a scaffolding command or a set of settings keys, so treat any such instruction you find elsewhere as unverified against this repository's documentation rather than as something the project guarantees.

Where Mezzanine is the wrong tool

The first limitation is release cadence. The most recent release listed is v6.1.1 from 2025-06-04, with v6.1.0 and v6.0.1 earlier in 2025. The last push to the default branch was on 2026-04-19. That is recent enough that the repository is not dormant, but it is not a project that ships continuously, and a team that needs a CMS release every few weeks should weigh that before adopting.

The second is the bundling itself. If you only need a blog on top of Django, Mezzanine brings a page tree, a forms builder, an ecommerce module and a dashboard with it. You will carry all of that in your dependency tree and in your upgrade path. A smaller, single-purpose Django app would leave you less to maintain.

The third is operational. Mezzanine is a Django project you deploy and run. There is no hosted product behind it. The README directs support to a mailing list, an IRC channel and a GitHub issue tracker, and asks that security issues be emailed privately to [email protected]. Teams without anyone who can run a Django deployment, a database and a web server are outside the intended audience, and no amount of reading the feature list changes that.

Mezzanine against Wagtail and WordPress

The README itself invites the comparison to WordPress, saying Mezzanine resembles tools such as WordPress in providing an interface for managing pages, blog posts, form data and store products, but differs in providing most functionality by default rather than through modules. That is the honest framing. WordPress is a PHP application you install and configure, with a plugin ecosystem you draw on. Mezzanine is a Python framework you develop against, with the features already in the box.

Wagtail is the closer comparison for a Django team, and the difference is architectural. Wagtail is built around a page model and a StreamField for structured content blocks, and it is typically added to an existing Django project as an app. Mezzanine is closer to a project template: you start from it, and the page, blog and store models come with it. If your content is mostly free-form pages and posts, Mezzanine's bundled set covers the ground immediately. If your content is a set of heterogeneous page types assembled from reusable blocks, Wagtail's model is the more natural fit.

A third option is plain Django with django-cms or a hand-rolled admin. That gives you the smallest surface, at the cost of building the page tree, the blog and the forms yourself. The README's claim that Mezzanine is more integrated is exactly the argument against that path.

Maintenance, licensing and what to check before adopting

Mezzanine is licensed under BSD-2-Clause, stated in the README and present as a LICENSE file at the repository root. That is a permissive licence, which in practice means you can use it in closed-source products and modify it, provided the copyright notice and licence text are retained. This is a factual description of the licence terms, not legal advice; if the licence matters to your organisation, have counsel read the LICENSE file rather than this paragraph.

The maintenance picture from the repository is mixed but not alarming. The default branch is master, the repository is not archived, and the last push was on 2026-04-19. The release history is thinner: v6.1.1 in June 2025, v6.1.0 in April 2025, and v6.0.1 in April 2025. The gap between the last push and the last release means fixes may land on master before they reach a tagged version, so pinning to a release and tracking master separately is the safer arrangement.

Upgrade cost is the part the README does not address. Because Mezzanine bundles page, blog, form and store functionality, a version bump can touch templates, settings and migrations at once. The repository ships a CHANGELOG file and a tox.ini and pytest.ini test setup, so the changelog is where to look for breaking changes before an upgrade. There is no documented rollback procedure, so a database backup before migrating is the only recovery path the documentation supports.

Editorial conclusion

Adopt Mezzanine if your team already writes Django and you want a CMS whose templates, models and admin you can edit directly, with pages, a blog, forms and search present from the first migration. Do not adopt it if you need a hosted, click-to-install site builder, or if the project's release cadence has to match your own, since the newest release listed is v6.1.1 from 2025-06-04. Before committing, verify that the Django and Python versions you run are supported by the pinned release, and read the docs on content architecture and custom content types to confirm the page and blog models match your content plan.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. stephenmcd/mezzanine on GitHub