Django 6.0 Kills Your Celery Dependency (Maybe)

Django 6.0 shipped December 3rd with a feature that's been requested for over a decade: native background tasks. After years of developers reaching for Celery or Django-Q to send emails or process uploads outside the request-response cycle, Django finally includes a Tasks framework in the box.

But here's the thing nobody's saying in the release announcements: you still need to run the workers yourself. Django handles task creation and queuing, but execution requires external infrastructure. This isn't the zero-config solution some developers expected, and the community reaction tells you everything about managing expectations versus reality.

What Actually Changed

Django 6.0 introduces four significant features that modernize the framework for current application requirements:

Background Tasks Framework: Define tasks as decorated functions and enqueue them through a configured backend. The framework ships without a default database backend, which according to InfoQ coverage, has "drawn criticism from some users" who wanted something that works out of the box for simple use cases like sending emails.

Native Content Security Policy Support: The new ContentSecurityPolicyMiddleware lets you configure CSP headers through Python dictionaries instead of third-party packages. This is the kind of security feature that should have been built-in years ago—better late than never.

Template Partials: Named template fragments that can be defined and reused within a single file using partialdef and partial tags. Google Summer of Code contributor Farhan Ali Raza built this feature, mentored by Carlton Gibson. For teams using HTMX or similar approaches, this reduces the need to split every reusable component into separate files.

Modernized Email API: Adopts Python's EmailMessage class for cleaner, Unicode-friendly email composition. A small change, but one that eliminates friction for a common task.

The release supports Python 3.12, 3.13, and 3.14 while dropping support for Python 3.10 and 3.11. Django 5.2 reached end of mainstream support with this release, though it will receive security fixes until April 2028.

The Background Tasks Reality Check

The Tasks framework is the headline feature, and community response ranges from enthusiastic to skeptical. One Hacker News user commented: "I love Django, and the new tasks framework to replace celery looks great." But a Reddit user offered the counterpoint: "Very disappointed that the new background task doesn't come with a default basic db backend and worker as it did in the original django-task. That would have covered the needs of so many basic apps where you just need them to send some emails and run some crons."

This tension reveals the framework's actual design: Django provides the interface and queuing mechanism, but you're still responsible for running workers. For teams already operating Celery infrastructure handling millions of daily requests, this changes nothing. For small projects that wanted to avoid that complexity entirely, it's not the silver bullet they hoped for.

The practical impact depends on your scale:

Template Partials and Component Architecture

The template partials feature addresses a real pain point. Previously, creating reusable template components meant either splitting everything into includes (file system overhead) or duplicating code (maintenance nightmare). Now you can define named fragments within a single template file and render them selectively.

This pairs naturally with HTMX and similar libraries that request partial page updates. Instead of creating separate endpoint templates or complex template inheritance hierarchies, you define partials inline and render exactly what you need. For teams building interactive applications without heavy JavaScript frameworks, this is a meaningful improvement to Django's server-rendered approach.

CSP Support: Security as Default

Built-in Content Security Policy support through ContentSecurityPolicyMiddleware brings browser-level security controls into Django's core. Configure policies using Python dictionaries and Django-provided constants rather than hand-crafting headers or depending on third-party middleware.

For new projects, this makes implementing CSP straightforward. For existing projects using packages like django-csp, the migration path is clear but not urgent—the third-party packages still work fine. The real value is establishing CSP as a standard security practice rather than an advanced technique requiring additional dependencies.

What This Means for Your Stack

Django 6.0 represents evolution, not revolution. The framework continues its pattern of incorporating mature third-party solutions into core functionality—but with careful API design rather than simply bundling existing packages.

The background tasks framework provides structure without imposing implementation details. Template partials enable component-based development without requiring a JavaScript framework. Native CSP support establishes security best practices as defaults.

None of these features fundamentally change how you build Django applications, but together they reduce the surface area of third-party dependencies for common requirements. That's valuable for long-term maintenance, security updates, and onboarding new developers who can work with framework primitives instead of navigating ecosystem choices.

According to market research, Django holds approximately 33% market share in the web framework category. This release signals the framework's commitment to remaining relevant as application requirements evolve—adding modern features while maintaining the pragmatic, batteries-included philosophy that built that adoption.

The Bottom Line

Upgrade if you're starting a new project or already planning to modernize your stack. Django 6.0's features reduce dependency sprawl without introducing complexity. The background tasks framework won't eliminate your Celery installation overnight, but it provides a cleaner foundation for future development.

For existing projects on Django 5.x, upgrade before April 2028 when security support ends for 5.2. The feature additions justify planning migration during your next major development cycle, not emergency weekend deployments.

The upgrade guide on the Django documentation covers breaking changes and migration paths. Read it before upgrading production systems—there are deprecations and behavior changes that require attention.

Django 6.0 does exactly what a mature framework should: evolve thoughtfully, incorporate proven patterns, and reduce friction for common tasks. Just don't expect it to solve infrastructure problems with framework features. You still need to run those workers yourself.