The CMS Is Not the Application

But your customer portal didn't suddenly become a CMS project. That distinction matters more than it might seem.

A lot of CMS architecture starts with the CMS and works outward. You choose a CMS, put content into it, and then figure out how your application, authentication, business logic, APIs and frontend should fit around it.

For a content-driven website, that can be exactly the right approach.

For an application, I think we should turn the relationship around.

The application should own the architecture. The CMS should provide a capability.

That's one of the ideas at the heart of how I think about django CMS.

Not everything with pages is a website

We tend to use "website" and "web application" interchangeably, but they lead to quite different architectural decisions.

Consider a campaign site, magazine or corporate website. Content is the product. Pages, navigation, media and editorial workflows naturally sit at the center of the architecture.

Now consider a customer portal, university platform, marketplace, intranet, or SaaS product.

These systems contain content, sometimes a lot of it. But content isn't the entire system.

A university platform might have courses, students, applications, accounts, payments and internal workflows. It also needs departments to maintain landing pages, course introductions, faculty profiles and campaign content.

A marketplace has products, sellers, transactions and customer accounts. It might also need buying guides, landing pages and editorial collections.

Giving non-developers control over that content is important. But it doesn't follow that the CMS should become the architectural center of everything else.

Your application shouldn't become a CMS project just because somebody needs to edit a page.

The architectural inversion

The interesting question is not whether an application needs content management. Many do.

The question is what happens when we let that requirement determine the architecture of the whole system.

Suddenly we're asking questions like:

• How do we represent our application's data in the CMS?
• How do we integrate our existing authentication?
• Where should our business logic live?
• How do we connect our services?
• How does the CMS communicate with our application?
• How do we preview application data together with editorial content?
• Which system owns permissions?
• Which system owns the URL?

None of these questions is inherently bad. Sometimes separating these concerns is exactly what we want. But we shouldn't arrive at that architecture simply because someone said, "We need a CMS."

Content management should not automatically determine application architecture.

This is especially relevant in the Django world, because Django is already very good at being an application platform.

Django is the application platform

Django gives us a mature foundation for building applications.

We have models and an ORM. Authentication and permissions. URLs and middleware. Forms, templates and views. APIs. Background jobs. Integrations. And, most importantly, the freedom to write ordinary Python for the parts that are specific to our domain.

A Django application might conceptually look something like this:

Django application
│
├── Accounts
├── Products
├── Orders
├── Search
├── APIs
├── Integrations
│
└── Content management
    └── django CMS

I find this model much more useful than thinking about the CMS as the container for the application:

CMS
│
├── Pages
├── Content
├── Users
│
└── "Custom application stuff"

The difference might look semantic, but it changes how we think about responsibilities.

The application owns. The CMS composes.

Django owns the domain models, business rules, authentication, transactions, APIs, and integrations. django CMS adds editorial composition to that application.

That's a big reason why being built on Django matters. It isn't merely an implementation detail or a convenient choice of Python framework. It means the CMS and the application can live in the same architectural world.

Content and application data can coexist

Consider a conference platform.

The application has Django models for:

• events
• speakers
• venues
• tickets
• registrations
• user accounts

Editors don't need a CMS to manage ticket transactions. Those belong to the application.

But they might want to create a conference landing page:

[Editorial hero]
[Editorial introduction]
[Upcoming events — application data]
[Editorial promotion]
[Featured speakers — application data]
[Newsletter component]

Some parts are editorial.Others come directly from the application.

The visitor doesn't care about that distinction. It's one experience. And the editor shouldn't have to understand the internal architecture to assemble it. This is where I think the CMS becomes particularly interesting: Instead of importing or duplicating all of our application data into a separate content universe, we can expose capabilities from the application to the editorial environment.

An "Upcoming events" component doesn't need the editor to manually maintain a second list of events. It can query the application's event data. A "Featured speakers" component can use the same speaker models as the rest of the application.

The application remains the source of truth. The CMS gives editors a way to compose experiences from it.

Developers define capabilities. Editors compose experiences.

Developer control and editor freedom aren't opposites.

A good CMS can give editors substantial freedom precisely because developers can define reliable building blocks.

Developers can create components, models, integrations, templates, constraints and business rules. Editors can then use those capabilities to compose pages and experiences without needing to know how the underlying application works.

That relationship is important. An editor shouldn't need to know how an event query works. They should be able to say: "Show the next three events from this category."

The developer shouldn't need to hard-code every page where events appear. They should provide the capability once.

The CMS sits at that boundary.

Developers define what the system can do. Editors decide how those capabilities are used to communicate.

That is a much more interesting role for a CMS than simply storing rich text.

Headless is a delivery choice

None of this requires choosing between "traditional" and "headless" CMS architecture.

Headless is useful, and we're investing in headless capabilities in django CMS. But headless describes how content is delivered; it doesn't answer who should own the application architecture.

A project might use a Next.js frontend. The same content might need to reach a website, a mobile application, and another service. Frontend and backend teams might need independent deployment cycles.

In other cases, having Django render the page is the simplest and most maintainable architecture.

And plenty of systems need both.

A public site might be rendered by Django while some content is exposed through APIs to a mobile application. Another project might use a separate frontend for one part of the experience while using Django templates elsewhere.

Delivery architecture should follow application requirements.

The CMS should give us options rather than force an ideological choice between headless and traditional architectures.

What this means for django CMS

This way of thinking explains a lot about django CMS: it lives inside a Django project.

• You can use Django models for your domain.

• You can build ordinary Django applications.

• You can create CMS plugins and components that interact with those applications.

• You can use Django's authentication and permissions.

• You can integrate external services.

• You can render with Django.

• And increasingly, you can use django CMS in hybrid and headless architectures when that's what the application requires.

Individually, those are features. What matters is the architectural principle connecting them:

django CMS should adapt to the application rather than forcing the application to adapt to the CMS.

It should become easier to expose application capabilities to editors, easier to build reusable and governed components, and easier to choose which content Django renders directly and which content is consumed through APIs.

Those choices should follow the application's requirements, not the limitations of its CMS.

This isn't the right answer for every website

There's an important caveat: Not every project needs this architecture.

If you need a straightforward marketing website and want a completely managed no-code service, django CMS may not be what you're looking for.

If you want a hosted product where somebody else makes every infrastructure decision for you, there are excellent products built specifically for that.

And if your entire product is essentially a repository of structured content delivered through APIs, a dedicated headless CMS might be the simplest choice.

That's fine.

I don't think django CMS needs to be the CMS for everything. In fact, trying to be the CMS for everything would probably make it worse at the things that make it interesting.

The opportunity is more specific: There are a lot of serious applications built with Django. Those applications increasingly need sophisticated content management: editorial workflows, localization, reusable components, previews, structured content and flexible delivery.

Developers shouldn't have to abandon the architecture and ecosystem they already have just to provide those capabilities.

A CMS for Django applications

There's a subtle but important difference between these two descriptions:

django CMS is a CMS built with Django and django CMS provides content management for Django applications.

The first tells you something about our technology. The second tells you why the project should exist.

I prefer the second.

I want django CMS to make content management a natural capability of a Django application. Developers should to be able to build the application architecture that makes sense for their problem. I want editors to get powerful tools without having to understand that architecture. And I want the boundary between application data and editorial content to become easier—not harder—to work with.

The CMS is important. But the CMS is not the application.

The application should own the architecture. The CMS should make it editable.