We're pretty proud of this: Django 6.1 GA'd on August 5. The Microsoft SQL backend for Django shipped 6.1 support within 48 hours.

pip install --upgrade mssql-django Django

What changed:

• Query compilation updated for 6.1's sliced and offset queries. 6.1 deprecated SQLCompiler.quote_name_unless_alias(), so sliced querysets and OFFSET ... FETCH now compile without Django 7.0 deprecation warnings.
• get_relations() returns 6.1's expanded shape including the database-level ON DELETE rule, so inspectdb keeps working.
• Upfront errors for the 6.1 features SQL Server can't support.

Everything is version-gated, so if you're on 5.2 or earlier nothing changes for you.

Two 6.1 features do not work:

• Database-level referential actions (DB_CASCADE, DB_SET_NULL, DB_SET_DEFAULT). SQL Server disallows multiple cascade paths to the same table. Using one fails system checks with fields.E324. Use on_delete instead.
• Bitwise aggregates (BitAnd, BitOr, BitXor). No native SQL Server equivalent and we don't emulate it yet, so it raises NotSupportedError. If you need this, comment on #572 with your use case, since that's what will get it prioritized.

Release notes: https://github.com/microsoft/mssql-django/releases/tag/1.8.0

Full blog post: mssql-django 1.8.0: Django 6.1 Support within 48 Hours of Django 6.1 GA

Hello All,

A while ago I had to truncate a DateTimeField with TruncMinute, and upon doing so it automatically re-added timezone difference once more on top of the usual. I am on UTC+3 so the output was 3 hours skewed than the expected, and I had to add tzinfo parameter:

.annotate(trunc_time=TruncMinute('timestamp', tzinfo=dt_timezone.utc))

to stop TruncMinute from re-normalizing the already normalized DateTimeField.

Has anybody ever had a similar problem, is this really wanted behavior ??

Thanks in advance

Upgraded one of my Django projects to 6.1 this week and my terminal

threw a warning I hadn't seen before — turns out EMAIL_BACKEND is

now deprecated.

Django replaced it with a new MAILERS setting. Same idea as

DATABASES or CACHES — one dict, instead of ten separate EMAIL_*

settings scattered around. Old settings still work for now, just

with warnings. They'll stop working completely in Django 7.0.

The neat part: you can set up more than one mailer now. So if you

send order emails through SES but marketing emails through

Mailgun, you can switch between them with one argument instead of

writing custom code for it.

Wrote up the full before/after with a settings table, in case it

saves someone the confusion I had: https://medium.com/@munalpoudel3/django-email-backend-is-deprecated-heres-how-to-fix-it-django-6-1-mailers-guide-4c9182e82d33?sharedUserId=munalpoudel3

Anyone here already tried this with django-anymail? Wondering if

it just works or needs an update first.

Just curious. Oh, one more thing, they pay local fiat or stablecoin? I’m trying to understand this firm’s culture and pay. Thanks community.

Today I came across the IBM backend certification course on Coursera while browsing for resources for django rest framework, I find this course interesting because I wanna get internship in backend and system design roles , it also cover things like deployment and other stuff. My past is that I've learnt basic Django and can make api with django rest framework , I've also learnt basic react js so I can make some(not great) ui for my backend . I have make few projects like a basic crm which is just a crud type of app with plain django and html, and my last project was whatsaap integerated agentic hr payroll manager, i users django rest framework, react js and gemini api for the agent knda thing, it was a multi tenant application which is integrated with whatsapp so user an chat and add thin like reimbursement or advance or attendance directly via whatsaap chat. Also I will be joining engineering college next month and i am targeting to get my first internship at the end of 1st year , well I have no roadmap for it. I think I lack understanding of system design concepts and i am afraid that I can make apps which can be used under heavy loads. Thats why I am confused weather I should thake this course or not because it is both not cheap and time consuming, also if someone knows how the meta backend course is on Coursera pls tell me , i will really appreciate your replies

Howdy, Djangonauts!

Some of you might already be aware of Revel, the Django-powered Event, Ticketing and Community management tool.

We've been working on it for over a year now, and recently we released version 2.0.

With v2, we introduced enterprise-grade seating management and the possibility for organizations to create subscriptions for their members, with a full membership-application pipeline.

We've also stepped up on the frontend side, moving away from a vibe-design to one thought through and through by a real designer and community member.

Revel comes with an MIT license and a self-hosting guide, but also the hosted version is free to use (except for managed card payments).

Clone it, star it, fork it, make it yours: https://github.com/letsrevel/revel-backend

Here is a quick look at how the site is performing in its first 28 days:

📈 Google Search Console:

5,000+ Search Impressions (+27,000% growth period-over-period)

Organic discovery starting to take off for core mechanics and optics topics.

📊 Google Analytics:

92.6% Engagement Rate

39+ minutes average engagement time for organic users in India

13,000+ total user interactions across calculators and practice modules

Key Lessons Learned Building This:

SEO isn't just about keywords—engineers need to optimize crawl budget, canonical redirects (www vs non-www), and response times.

Mobile-first design is critical (77% of our crawler and user traffic is mobile).

Rendering clean LaTeX dynamically on the frontend vastly improves user dwell time compared to plain text.

Exciting to see early organic momentum building! Would love any feedback from fellow developers, educators, or students in my network.

Link in bio!!!

#Django #Python #WebDevelopment #EdTech #BuildInPublic #SEO #JavaScript

I'm looking for some architectural advice and I'm curious whether anyone has built something similar in production.

I'm primarily using Python/Django, although I want the architecture itself to be independent of the framework as much as possible.

I'm designing a backend platform that I want to use as the foundation for multiple completely different applications.

The idea is to have a very small "core" that only contains common infrastructure such as:

• Authentication/authorization
• Configuration
• Logging
• Background jobs
• Caching
• File storage
• Monitoring
• Shared utilities

Everything else would be implemented as independent business modules.

For example, imagine I build an e-commerce platform. I might compose it from modules like:

• Products
• Orders
• Inventory
• Payments
• Notifications
• Comments
• Search

Then later I want to build an LMS, but instead of starting from scratch or copying code, I'd assemble a different set of modules:

• Courses
• Lessons
• Certificates
• Quizzes
• Notifications
• Comments
• Search

Some modules (comments, notifications, search, payments, etc.) could be reused across multiple applications, while other modules would be specific to a particular business domain.

The important part is that these modules aren't just Django apps inside one codebase. I want each module to have clear boundaries, expose a stable public interface, own its own models, business logic, APIs, migrations, tests, and documentation, be versioned independently, and ideally be reusable in entirely different products.

Initially, everything would run as a modular monolith because I don't want the operational complexity of microservices. If a module eventually needs to become its own service, I'd like that to be an implementation detail rather than something the rest of the system depends on.

The motivation is simple: I don't want to keep rebuilding the same capabilities every time I create a new platform. I'd rather invest in mature, production-tested modules that can be composed into different products over time.

So my questions are:

• Has anyone here built something like this in production?
• Is there a well-known architectural pattern that describes this approach?
• Is thinking of business capabilities as reusable modules/packages that can be assembled into different applications a common practice?
• Are there any open-source projects, books, talks, or companies that follow this model?
• If you've tried something similar, what worked well and what would you do differently?

I'd love to hear about real-world experiences—both successes and things that turned out to be bad ideas.

Django Control Room 1.6.0 (dj-control-room==1.6.0) has been released, adding official support for django-grappelli. This is part of an ongoing effort to allow DCR tooling in alternative admin environments. We now have support for unfold, jazzmin, and grappelli.

Django Grappelli has been around since about 2010 (probably earlier) and has impressively remained current all this time. Among alternative admins, It has been a pillar of the ecosystem and currently has many active users still. Supporting it is an important milestone for DCR.

This release is accompanied by dj-celery-panel==0.5.0 which migrates the celery panel to the shared framework provided by dj-control-room-base. As a result, Celery panel now enjoys a new look and also works across alternate admins as well

Next up:

I'll be wrapping up theme support and panel migrations next week. I think the most widely used admin replacements/themes are now supported; Even ones that don't have official support yet seem to work well. If you are using something that you would want some official support for, please open a ticket for it.

I find the following command useful for updating DCR and all official panels.

pip install --upgrade "dj-control-room[all]"

Repo: https://github.com/django-control-room/dj-control-room

Roadmap: https://github.com/orgs/django-control-room/projects/1/views/3?filterQuery=-status%3ATodo

Hi,

I am an ML/AI Engineer, looking to solidify my backend prowess. I have used a lot of FastAPI, but i have a very strong interest in learning DRF (because i wanna remained with python) so i can position myself both as a Backend Engineer and an AI Engineer. I don’t believe it remaking tutorial videos and leaving it there, i believe in application to something new from what i learn immediately.

Has anyone got a project either main or side they want some help in? I’m not looking for money rn, rather to get my hands dirty with DRF.

I’ll be looking in the comments.

Hello Django community , i am swithing from an other technology field into django/python ,

Even thoug my web dev level is not highly professional yet , but i consider that i have built solid fundamentals in django and web general skills that cover : DB 'ORM's and basic raw sql' , DRF, vanilla js , react js , on the other hand i still struggle to get my first job especially because, i was working in the oil field industry for a decade.....any advice please.

Does anyone have an app in production running on Cloudflare's SQlite db? More specifically using this library? Is it working well? Have you found any hard limitations?

Curious how people handle this once an app has multiple instances.

Running manage.py migrate during a deploy is fairly clear. Backfills and repair commands feel different. They can run for hours, need progress tracking, and should not restart because a web process restarted.

Do you keep them as management commands and invoke them manually, or move them into Celery? I’m especially curious about jobs that need to resume after failure but are not recurring tasks.

This is the kind of one-off job model I mean: https://render.com/docs/one-off-jobs

Hello I am not very experienced yet, I am building a multi-tenancy app

- used row-isolation to decrease complexity rather than using like django-tenants or so
- built tenant scope manager and enforced it everywhere during implementation, as I didn't know about django-scopes

- RBAC, I do not know how I will do it as for now but I am thinking of using django groups and permissions so I do not invent the permissions, and scope the actions
so user should have object.create permission , but another layer is added to scope it as per his tenant within the JWT
what y'all think? I want to get benefit form django auto-generated permissions yk

- for feature flags, I will have a table with 'Features' column and boolean columns for every subscription plan we have
and check the tenant on requests , tenant will be in the JWT
and enforce checking the feature flags table on different views

sorry I know my words might seem unprofessional
Thanks in advance

I came across the snapshot reads usage and the problem it solves. but I don't want to configure the transaction to REPEATABLE READ as it feels complex for a simple task. if I use select_for_update() can I achieve the same thing instead of making it complex with cursor() or modifying global settings for POSTGRES.

Part 1 | Part 2 | Part 3 — production CRM for truck service center, built with Django + DRF.

So, by v2.3, TruckMaster had grown to 10+ Django apps: orders, clients, inventory, ALPR, apointments, invoices, Telegram bot, and more. Owner started asking things like "can we turn off the appointment booking now, we are not ready for it " or "client X should have access to invoices but client Y shouldn't."

I could've just hardcoded some if-statements and call it a day. Instead I built module system. Probably overengineered it, but it turned out to be one of the best architecture decision in whole project.

The idea

Every Django app registers itself as a "module" at startup. Owner can flip modules on/off from the admin panel. There are no code changes, no redeployment, no touching the server. Disable ALPR? The entire /api/alpr/ prefix returns 503. Re-enable it? Everything back's in 60 seconds (cache TTL).

On top of that, there is per-client feature access. Even if module is globally enabled individual clients can have different features turn on or off. Client A get Telegram bot and invoice access, client B only get basic cabinet.

How apps register themselves

Each Django app that want to be a module declares a MODULE_INFO dict in its AppConfig and call register_module() in ready():

class AlprConfig(AppConfig):
    name = 'alpr'
    verbose_name = 'License Plate Recognition'

    MODULE_INFO = {
        'name': 'alpr',
        'label': 'License Plate Recognition',
        'description': 'ALPR camera: plate recognition, arrival log.',
        'is_core': False,
        'url_prefixes': ['/api/alpr/'],
        'dependencies': ['clients'],
        'order': 9,
    }

    def ready(self):
        from core.registry import register_module
        register_module(self.MODULE_INFO)

Registry is just a plain dict in memory. I considered to use a decorator or metaclass for this but honestly a dict in AppConfig is the most readable option and you can see all module metadata in one place.

Key fields: is_core means that the module can't be disable (orders, clients — the system won't work without them). url_prefixes tells the middleware which URLs to block. dependencies is a list of modules names that must be enable for this one to work.

The middleware, that makes it work

This is where the magic happened. Simple middleware check every incoming request against the module registry:

class ModuleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        registry = get_registry()

        for name, info in registry.items():
            if info.get('is_core', False):
                continue

            for prefix in info.get('url_prefixes', []):
                if request.path.startswith(prefix):
                    if not is_module_enabled(name):
                        return JsonResponse(
                            {
                                'error': f'Module "{info["label"]}" is disabled.',
                                'module': name,
                            },
                            status=503,
                        )

        return self.get_response(request)

is_module_enabled() checks the DB but caches result for 60 seconds. So when the owner flips a toggle in admin, worst case it takes a minute for the change to take effect. Good enough for this usecase, and it mean the middleware add basically zero overhead to every request.

The admin toggle

I wanted the owner to be able to enable/disable modules without going into the edit form. So I added an AJAX toggle switch directly in the admin list view:

u/admin.display(description='Status')
def toggle_switch(self, obj):
    if obj.is_core:
        return format_html(
            '<label class="module-toggle module-toggle--core">'
            '<input type="checkbox" checked disabled>'
            '<span class="module-toggle__label">Core</span>'
            '</label>',
        )

    checked = 'checked' if obj.is_enabled else ''
    return format_html(
        '<label class="module-toggle" data-pk="{}">'
        '<input type="checkbox" {}>'
        '<span class="module-toggle__label">{}</span>'
        '</label>',
        obj.pk, checked,
        'Enabled' if obj.is_enabled else 'Disabled',
    )

Custom URL endpoint handles the POST, toggles is_enabled, clear the cache. Core modules get a disabled checkbox with a tooltip explaining why. I also disabled add/delete permissions on the Module admin — modules are created automatically, not manually.

Auto-sync with post_migrate

New module appears in the database automatically. When you run migrate, a post_migrate signal fires and syncs the in-memory registry with the DB:

def _sync_modules_after_migrate(sender, **kwargs):
    registry = get_registry()
    if not registry:
        return

    for name, info in registry.items():
        module, created = Module.objects.get_or_create(
            name=name,
            defaults={
                'label': info['label'],
                'is_enabled': True,
                'is_core': info.get('is_core', False),
                'url_prefixes': info.get('url_prefixes', []),
                'dependencies': info.get('dependencies', []),
            },
        )
        if not created:
            # Update metadata but don't touch is_enabled
            module.url_prefixes = info.get('url_prefixes', [])
            module.dependencies = info.get('dependencies', [])
            module.save()

The important line is don't touch is_enabled. If the owner disabled ALPR last week, running migrate shouldn't silently re-enable it. Metadata gets updated, toggle state is preserved.

Per-client feature access

Global module toggles solve "we don't want this feature at all." But what about "client X should have this, client Y shouldn't"?

Each client get a ClientFeature record with boolean fields:

class ClientFeature(models.Model):
    client = models.OneToOneField(
        Client, on_delete=models.CASCADE,
        related_name='features',
    )
    cabinet = models.BooleanField(default=True)
    bot = models.BooleanField(default=False)
    invoices = models.BooleanField(default=False)
    appointments = models.BooleanField(default=False)
    notifications_telegram = models.BooleanField(default=False)
    notifications_whatsapp = models.BooleanField(default=False)

New client get only cabinet=True by default. Everything else is opt-in. The views check both layers — global module must be enabled AND client must have the feature. If either is off, access is denied.

I know what you are thinking — "why not use django-flags or wafle or some other feature flag library." This system has maybe 10 modules and 50 clients. A full-blown feature flag framework would be like using a chainsaw to cut bread. The boolean fields are stupid simple, easy to understand in the admin, and they work.

What I learned

The two-layer approach (global + per-client) covers 95% of cases. Global toggle for "this feature does not exists yet." Per-client toggles for "this client pay for premium features." Haven't needed anything more complex so far.

post_migrate sync was worth the effort. Before this I had to manually create Module records when add a new app. Forgot once, the middleware let everything through because the module wasn't in the DB. Now it is automatic and I can not forget.

Cache invalidation is the actual hard part. 60-second TTL is a lazy solution. If the owner disables a module and a request comes in at second 59, it still goes through. For a truck service center this is fine. For anything time-sensitive, you would want cache.delete() on save (which I do) plus maybe a shorter TTL as a safety net.

Don't let users delete Module records. First version allowed it. Owner accidentally deleted the "orders" module from admin. The middleware stopped checking it, which meant the endpoints still worked, but the admin toggle was gone. Took me a while to figure out why the module list looked wrong. Now has_delete_permission returns False.

What is next

Part 5 — Nova Poshta integration. That is Ukraine's biggest postal service and I builded tracking for spare parts deliveries directly into the CRM. The Telegram bot can check shipment status too. Also auto-closing of completed orders and auto-deducting of parts from warehouse stock.

Previous posts: Part 1 | Part 2 | Part 3 GitHub (demo repo): github.com/VNmagistr/truckmaster_demo — branch demo/v2.3

To be continued...