12 Aug 2026

feedDjango community aggregator: Community blog posts

Storing Django Static and Media Files on Cloudflare R2

This tutorial shows how to configure Django to load and serve up static and media files, public and private, via Cloudflare R2.

12 Aug 2026 3:28am GMT

11 Aug 2026

feedDjango community aggregator: Community blog posts

Duff's device in JavaScript

In 1983, Tom Duff needed to copy memory into an output register faster than his compiler could manage, and wrote the most famous abuse of switch in the history of C. I ported his device to JavaScript and raced it against the plainest possible loop - and the verdict changed with the engine, the engine's version, and the CPU underneath.

Duff’s device in JavaScript

11 Aug 2026 10:00am GMT

Managing email: peace of mind and efficiency with filters

Like probably everybody, I get a lot of email. Newsletters, weekly mails of some shops I want to monitor for handy discounts, linkedIn updates, GitHub/dependabot notifications, some left-over spam, calendar notifications, some Patreon stuff, etc, etc, etc.

Oh, and some real, individual emails! Oh, and spread over two accounts, work and personal.

Goal: less effort and lower maintenance

I want my inbox to be much more empty. I don't need it to be "inbox zero", but having to press the PageDown key four times is a tad much. And everything is mixed together, so if I start to clean up, I'm constantly having to switch between "determining if some GitHub mail can be deleted" and "reading an interesting long newsletter".

I get a low-level feeling of anxiety as I'm bound to miss or neglect important emails. And cleaning up the email is time-consuming as I'm constantly reading and ignoring the same email subjects (and not really dealing with them).

So: I don't want to have my email all mixed up. The inbox should be emptier. And I want to set it up in a way I can easily maintain it.

Solution: automatic filtering + post-holiday cleanup

During my holiday, I barely check my email. So the usual pile of email is even higher. The advantage of the big pile: all different kinds of email are visible in the inbox. If you clean/sort/filter/unsubscribe/whatever now, you'll probably have most different email sources covered.

Solution one: liberally unsubscribe from notifications and mailing lists. I've got enough interesting and diverse sources of information of my own, so I really don't need linkedIn's summaries (there's also more AI spam). I signed up for instagram to see one person's model railway photos, but I don't need the never-ending emails suggesting other people to follow. Also shop mailinglists where I signed up for to get some €5 discount on an order.

Solution two: multiple inbox folders plus automatic filtering. I want to keep my main inbox for the special or sporadic or important emails. So I created folders named inbox_someting and set up filters/rules to move emails into those folders automatically based on sender or subject. For my work email I have four:

inbox_alerts
Notifications about sites being down or colleagues' GitHub AI credits being drained.
inbox_calendar
Microsoft calendar notification emails. Microsoft's email/calendar integration is weird and non-standard and I seem to have to acknowledge meetings on every device I own. My solution now is to acknowledge meetings from this inbox and to use my iphone to actually look at the calendar.
inbox_github
Pull request emails, Dependabot messages, Renovatebot messages, issues being opened.
inbox_teams
Notifications from Microsoft Teams and from Slack.

My personal email has five, at the moment:

inbox_github
Same as for my work email, but then for my personal and open source projects.
inbox_leesvoer
"Leesvoer" is Dutch for "reading fodder". So all those interesting longer newsletters end up here. "Interesting" means "procrastination", so not having them directly in my main inbox keeps me from allowing myself to be distracted. And if I have some time, for instance during a bus trip, I can read some of them at leisure.
inbox_updates
Strava monthly summaries. Apple software update notices. Billing emails. Commercial emails that I'm allowing, like a DIY shop that I like to monitor for discounts. A venue I visit two times a year for a concert. Bank/insurance newsletter. Kickstarter/Bandcamp. Weekly postgress newsletter.
inbox_bnls
I'm moderator (and partially sysadmin) for a Dutch model railway forum (which is often abbreviated "bnls"). Moderation requests and personal messages end up here.
inbox_bnlsundeliver
Somehow I'm getting "email cannot be delivered" error messages from the forum now, so I'm stuffing them all in this folder for later cleanup of emailadresses in the forum. That way they don't clog up my inbox. This is probably a temporary inbox-folder.

Once in a while, I'll quickly look into inbox_updates. I'll read some of them. Most can be deleted. In any case, within no-time the folder will be empty. There's nothing in there I want to keep, normally. That's not something I could do that quickly when it was mixed with everything else in my single main inbox!

Same with quickly going through (and deleting) the GitHub notifications.

Emails that can be more important are in my main inbox. Or in inbox_alerts or inbox_bnls for instance.

Technical details

I'm running our "vanrees.org" email via the German mailbox.org. My work email is sadly Microsoft. I didn't really want to set up filters in a mail program (on my computer), as I want those filters to run continuously, also when I'm on holiday and my computer is stored away. And when the thing is sleeping in my backpack.

So... for my work email, I set up rules in Microsoft Outlook's web interface. There are just a few of them, basically just shuffling all GitHub stuff into inbox_github and meeting info in to inbox_calendar.

For my personal email, things are a bit more complex. Sure, the majority are simple rules, but some have "if from this address but with this subject"-like rules. That's why I landed (after some searching) on imapfilter. I run it on my Linux server via a cronjob. It has a configuration file that I can back up.

Some examples from my config file:

results = account1.INBOX:contain_from('notifications@github.com') +
          account1.INBOX:contain_from('@md.getsentry.com') +
          account1.INBOX:contain_from('noreply@github.com')
results:move_messages(account1.inbox_github)

results = account1.INBOX:contain_to('webmaster@beneluxspoor.net') *
          account1.INBOX:contain_subject('Undelivered Mail Returned to Sender')
results:move_messages(account1.inbox_bnlsundeliver)

And I took the opportunity to filter out some spam messages that somehow managed to slip around the normal spam mechanism:

results = account1.INBOX:contain_from('subaru') +
          account1.INBOX:contain_from('kontaktpush.de')
results:move_messages(account1.Junk)

Conclusion after a few days

So... pretty happy at the moment! My main inbox is much cleaner and keeping up to date is easier. Handling the other inbox-folders is also easier as there's just one category of email in them.

And... as I now have a system, I can expand it. I just looked at my inbox and saw a mail that ought to go into inbox_updates. Adding it, now that I have the system, is just one minute of work. Which will save me many minutes in the years to come!

11 Aug 2026 4:00am GMT

08 Aug 2026

feedDjango community aggregator: Community blog posts

Django: introducing django-msgspec

It's another day, another new package day here. Say hello to django-msgspec, a package of drop-in replacements for Django and Django REST Framework (DRF) components backed by msgspec.

msgspec is a C-based serialization library covering JSON, MessagePack, YAML, and TOML, with optional schema validation through typed Struct classes. Its JSON encoder and decoder are several times faster than the standard library's, which makes django-msgspec a cheap performance win in the parts of Django that handle JSON.

Features

There's a version of JsonResponse:

from django_msgspec.http import JsonResponse


def index(request):
    return JsonResponse({"title": "Hello, world!"})

…a test client with matching test case classes:

from django_msgspec.test import SimpleTestCase


class IndexTests(SimpleTestCase):
    def test_index(self):
        response = self.client.get("/", headers={"accept": "application/json"})
        assert response.status_code == 200
        # response.json() uses msgspec to parse the response body
        assert response.json() == {"title": "Hello, world!"}

…a version of Django's json_script template tag, which is where this whole story began:

{% load django_msgspec %}
{{ sales_by_product_id|json_script:"chart-data" }}

…and a handful of components that you activate purely through settings, with no code changes at all:

SESSION_SERIALIZER = "django_msgspec.sessions.JSONSerializer"

SERIALIZATION_MODULES = {
    "json": "django_msgspec.serializers.json",
    "jsonl": "django_msgspec.serializers.jsonl",
}

REST_FRAMEWORK = {
    "DEFAULT_RENDERER_CLASSES": ["django_msgspec.rest_framework.JSONRenderer"],
    "DEFAULT_PARSER_CLASSES": ["django_msgspec.rest_framework.JSONParser"],
}

That covers session storage and signing, dumpdata / loaddata in both JSON and JSON Lines, and DRF request parsing and response rendering.

Everything encodes with an enc_hook that knows about Django's lazy strings, so translated text passes through as you'd expect. It's all tested against the currently supported versions of Python and Django, with 100% coverage.

Déjà vu?

Only three weeks ago, I introduced django-orjson, a near-identical package backed by the Rust-powered orjson. So yeah, you might be confused why I made another faster-alternative-JSON-package-wrapper package so soon after the first one.

After releasing django-orjson, several folks from the community reached out to me telling me about the issues with orjson and pointing to msgspec instead. Additionally, while trying to roll out django-orjson on a client project, I learned that certain documented behaviours and limitations in orjson were going to be road blockers.

Here's a full list of what I learned:

  • Dictionary keys have to be strings. Take a mapping of object ID to some count:

    >>> import json
>>> json.dumps({1: "one"})
'{"1": "one"}'

>>> import orjson
>>> orjson.dumps({1: "one"})
Traceback (most recent call last):
  ...
TypeError: Dict key must be str

    JSON objects can only have string keys, so the standard library coerces non-string keys with str(). But orjson refuses to do so, with the justification that the coercion is lossy and the keys will come back as strings when deserialized. Thankfully orjson does have an option here, OPT_NON_STR_KEYS, that opts in to the standard library behaviour, but you gotta know about it!

  • Integers are limited to 64 bits.

    >>> json.dumps(2**64)
'18446744073709551616'

>>> orjson.dumps(2**64)
Traceback (most recent call last):
  ...
TypeError: Integer exceeds 64-bit range

    JSON itself sets no limit on number sizes, but RFC 8259 warns that implementations may, and many do-JavaScript, for one, silently loses precision beyond 253. orjson caps integers at 64 bits, matching native integer types, while Python's arbitrary-precision integers mean the standard library will happily emit larger values.

    In this case, orjson is probably more correct, but it is lacking an option to restore compatibility if required. (I didn't encounter any use case for massive numbers myself.)

  • There's nowhere to report problems.

    The orjson README sayeth:

    There is no open issue tracker or pull requests due to signal-to-noise ratio.

    I have plenty of sympathy for that decision, having felt the weight of my own project's issue trackers backing up. But it does mean that when you hit any problems, you can't check whether it's known, follow a fix, or contribute one. Your options are to read the CHANGELOG and hope, or to work around it yourself.

  • No sub-interpreter support, ever.

    The README also says:

    orjson does not and will not support PyPy, embedded Python builds for Android/iOS, or PEP 554 subinterpreters.

    I kinda missed this one when adopting orjson, but for me it's a bit of a concern. I think subinterpreters could support some cool use cases, like fast parallel test runners, and from my experience writing extension packages, support for them does not add much overhead.

    And this is not a soft limitation-you can't even import orjson in a sub-interpreter, let alone serialize anything:

    >>> from concurrent import interpreters
>>> interp = interpreters.create()
>>> interp.exec("import orjson")
Traceback (most recent call last):
  ...
concurrent.interpreters.ExecutionFailed: ImportError: module orjson.orjson does not support loading in subinterpreters

    It's a shame that the orjson maintainer advertises such a hard line here.

  • No free-threading support yet.

    orjson currently publishes no wheels for free-threaded Python, which is now "stable" as of Python 3.14. On a free-threaded build, you're forced to compile the Rust package from source, which is a bit of an adoption blocker for large teams.

  • Pydantic decided against it, on trust grounds.

    Back in 2019, a contributor opened a pull request to use orjson in Pydantic, and Samuel Colvin declined it. His stated reasons were:

    1. orjson's author gives no name or personal details on GitHub.
    2. The author had privately emailed Sam asking for the integration, and he was "surprised and somewhat worried by the hostile response I got when I made his/her request public".
    3. The compiled wheels for the package could potentially contain malicious code, which seems like more of a risk given the author's anonymity.

    He was careful to add: "Let me make it clear: I'm not accusing <the maintainer> of anything, I'm 99% certain that his/her intentions are honourable."

    I have the same feelings, now that I'm aware of all the (public) details of orjson. Pseudonymity is entirely legitimate and plenty of excellent software is written under a handle, and this was seven years ago. But stack it up with the closed issue tracker, and it does mean that installing orjson means trusting a compiled binary from a maintainer who has chosen not to engage in public at all.

msgspec's advantages

msgspec answers the questions raised by the above points against orjson:

  • It handles numerical keys the way the standard library does:

    >>> import msgspec.json
>>> msgspec.json.encode({1: "one"})
b'{"1":"one"}'

  • It encodes and decodes large integers:

    >>> import msgspec.json

>>> msgspec.json.encode(2**64)
b'18446744073709551616'

>>> msgspec.json.decode(b"18446744073709551616")
18446744073709551616

  • It has an open issue tracker.

  • msgspec fails to import in sub-interpreters right now, but the issue is being worked on by the maintainer and contributors.

  • msgspec publishes free-threading compatible wheels today.

  • The creator is not anonymous and the project is now maintained by a group in a GitHub organization, featuring at least Nikita Sobolev who I have known online from other open source projects (especially django-stubs).

And most importantly, msgspec's encoding and decoding are in the same performance ballpark as orjson's!

msgspec has standard library incompatibilities too

By the way, msgspec isn't fully compatible with json-here are the differences that I know about.

  1. Non-finite floats are encoded as null rather than the standard library's NaN and Infinity:
>>> json.dumps(float("inf"))
'Infinity'

>>> msgspec.json.encode(float("inf"))
b'null'

I'd call this an improvement, since Infinity isn't valid JSON and other parsers will reject it. But it is a change, so if you rely on round-tripping those values, take note.

  1. msgspec also only coerces keys that are string-like or number-like, so booleans and None are still rejected:
>>> json.dumps({None: "nothing"})
'{"null": "nothing"}'

>>> msgspec.json.encode({None: "nothing"})
Traceback (most recent call last):
  ...
TypeError: Only dicts with str-like or number-like keys are supported

Such keys should be rarer than numbers in practice.

What might come next in django-msgspec

django-msgspec covers the same ground as django-orjson today, but msgspec is a broader library than orjson, so there's more potential for future development.

First, msgspec's typed container class, Struct, lets you decode and validate in a single pass:

>>> import msgspec
>>> class Sale(msgspec.Struct):
...     product_id: int
...     count: int
...
>>> msgspec.json.decode(b'{"product_id": 1, "count": 2}', type=Sale)
Sale(product_id=1, count=2)

>>> msgspec.json.decode(b'{"product_id": "one", "count": 2}', type=Sale)
Traceback (most recent call last):
  ...
msgspec.ValidationError: Expected `int`, got `str` - at `$.product_id`

This could be useful for combining with Django views, DRF parsers, or even forms.

Second, msgspec can serialize and deserialize other data types, so they might be worth integrating.

Happy to take suggestions on the design here, on the issue tracker.

Fin

Please try out django-msgspec today and let me know how it goes.

May all your messages be to specification,

-Adam

08 Aug 2026 2:24am GMT

07 Aug 2026

feedDjango community aggregator: Community blog posts

Issue 349: Django 6.1 and a DSF Executive Director

News

Call for applicants for a Django Executive Director

The DSF is hiring its first Executive Director to run fundraising, operations, staff, and legal/compliance for the Foundation. The role is US-based (no visa sponsorship). Applications (resume, optional cover letter, and a vision statement) are due September 14, 2026.

Django 6.1 released

Django 6.1 introduces model field fetch modes, database-level delete options for ForeignKey.on_delete, and dictionary-based email settings. Django 6.0 is now out of mainstream support and receives security and data loss fixes only until April 2027, so plan your upgrade before then.

Thank you to release manager Jacob Walls and the entire Django team on another happy feature release.

Releases

Django security releases issued: 6.0.8 and 5.2.17

The releases address high-severity spatial lookup flaws that could write files or make network requests, plus denial-of-service risks in language and geometry handling and potential XSS from unsafe admin URLField values. Upgrade to Django 6.0.8 or 5.2.17 as soon as possible.

Python 3.15.0 candidate 1 is here!

Python 3.15.0 candidate 1 is available for testing, giving projects a release candidate against which to check compatibility and build wheels.

Python 3.14.7 and 3.13.15 are now available!

Python 3.14.7 and 3.13.15 are available as bug-fix releases, so update your installations.

Wagtail CMS News

An agent-heavy roadmap for 2026

A standards-based look at what agent readiness requires, without the usual hype.

Sponsored Link

Find and fix Python errors faster - for free - with Honeybadger

When something breaks in production, logs tell you something happened. Honeybadger tells you why.

Honeybadger filters out noise and transforms your Python logs into context-rich issues so you can stop guessing and ship the fix faster.

Django Fellow Reports

Django Fellow Report - Jacob

Highlights this week included clearing release blockers for 6.1 and making the parallel test runner more fault tolerant. That means lots of tickets triaged, reviewed, and authored!

Django Fellow Report - Natalia

This week I prioritized time-sensitive security work 🥷, including finalizing patches, preparing and validating backports, and sending pre-notifications ahead of the release. Alongside that, I focused on Tim's "Sprint quickstart" PR 🏃‍➡️ and attended meetings 🎧. Otherwise, I spent time preparing my DjangoCon US talk (it is coming together well, even if I am a bit wary of expectations around my htmx expertise 🎤).

Django Fellow Report - Sarah

Focus of the week was mostly around helping finalize the security release and reviewing the GSOC Selenium to Playwright migration (which is looking in good shape!).

Articles

Django Claude Skills

Mariatta built a set of Django house rules for Claude to follow in her own projects, covering formatting (black, isort, djlint, flake8), full test coverage as a merge requirement, has_perm() over group-membership checks for permissions, and a single Markdown email template that renders both text and HTML. She's explicit that these are personal conventions, not Django community consensus, and that a project's own style wins when contributing elsewhere. She published it as an Astro static site rather than plain Markdown, since she'd rather read the rules in a browser than as agent-only files.

What I love about Django

The best parts of Django are the ones you stop noticing - a tour of the abstractions that have given Buttondown the most leverage over the years.

Django Doesn't Have to Feel Old: Modernize Your Frontend with Vite

A walkthrough of wiring django-vite into a Django project: hot module replacement so CSS edits show up without a full page reload, explicit imports instead of global script-tag collisions, and a vite_asset template tag that resolves to the dev server or hashed production files depending on DEBUG.

Django 6 isn't a revolution. And that's exactly why I like it.

An experienced developer's take on years of building applications with Django and why the latest update continues a philosophy that many modern frameworks seem to have forgotten.

Python: how time-machine is O(1) where freezegun is O(n)

The comparison explains why time-machine avoids freezegun's O(n) slowdown when mocking dates and times, building on benchmarks that found it 100 to 200 times faster across two project sizes.

Core Dispatch #9

Python 3.15.0 release candidate 1 is out, followed by maintenance releases Python 3.14.7 and 3.13.15. The latest Core Dispatch also tracks two new PEPs entering the queue.

Devtools must be open source

Agents can now rebase your local tweaks against upstream automatically, so personalizing a tool costs a prompt instead of an ongoing maintenance burden. That's the case for why closed-source tools like Claude Code can't be personalized the way open alternatives like Codex or Pi can.

DjangoCon US

Save 10% on DjangoCon US 2026 registration

DjangoCon US 2026 runs August 24 to 28 in Chicago, now under three weeks away. Register through our link to take 10% off. Time is running out to get your ticket. Get yours before they are gone!

Events

Chicago Like a Local: Things to Do During DjangoCon US 2026 (Part 1)

Conference chair Keanya Phelps rounds up Italian beef at Mr. Beef and Al's, ramen and vinyl records at Wax in West Town, shuffleboard at Electric Shuffle, and rooftop lake views at Offshore on Navy Pier. She also flags the free Chicago House Music Festival in Millennium Park, August 27 to 30, which overlaps the last days of the conference.

Django Job Board

A few openings this week, including Django and Python Software Foundation roles.

Executive Director at Django Software Foundation 🆕

Security Developer at Python Software Foundation

Senior Full Stack Engineer at Hive Collective

Senior Backend Engineer at MyOme

Python + TypeScript Engineers at Fusionbox

Videos

PyCon US 2026

PyCon US 2026 videos are up.

Projects

wemake-services/django-modern-rest

Modern REST framework for Django with types and async support!

wsvincent/django-skills

Unofficial Django skills based on Django docs and community best-practices.

07 Aug 2026 3:00pm GMT

04 Aug 2026

feedDjango community aggregator: Community blog posts

`break`/`continue` is the new `goto`

"Go To Statement Considered Harmful" is one of the most-quoted titles in programming, and almost nobody reads past it. The argument underneath is narrower than the slogan it became - and the reflex it bred, avoiding every jump, produces code worse than the goto it was meant to replace.

break/continue is the new goto

04 Aug 2026 10:00am GMT

03 Aug 2026

feedDjango community aggregator: Community blog posts

Running Headscale on my own infra (and finally killing my WireGuard setup)

Hello everyone 👋

This one started in the dumbest possible way: I wanted to check on my 3D printer from outside my house.

I have a Bambu printer running in LAN-only mode, and I use OctoApp to control it from my phone. Works great at home. Useless the moment I leave. The usual answer is OctoEverywhere, which is a lovely project, but it means my printer traffic goes through someone else's servers, and I already run enough infrastructure that this felt silly.

So I went looking for a way to just… have my home network with me. And I ended up rebuilding my entire remote access setup in an afternoon.

What I had before

My old setup was, in hindsight, a bit of a Rube Goldberg machine:

Two Pi-holes. Two address ranges. Two mental models of "where am I right now". It worked, but every time I added a service I had to think about which side of the tunnel it lived on.

What I actually wanted was much simpler: when I'm away, I want my phone to behave exactly like it's sitting on my home WiFi. Same IPs, same DNS, no difference at all.

That's a mesh VPN, and the nicest one is Tailscale.

I don't trust free

Tailscale is excellent. I want to say that first, because what follows is going to sound like criticism and it isn't. The client is great, the free tier is generous, and for most people it's the right answer.

But every time I look at a free tier this good, I catch myself doing the same mental arithmetic: someone is paying for this, and it isn't me. Tailscale is a venture-funded company. Free tiers built on top of venture funding have a well-documented lifecycle, and the last chapter is rarely "and it stayed free and generous forever". The limits shrink, or a device cap appears that you're already over, or the company gets acquired by someone with different ideas.

I'm not predicting that Tailscale does any of this. I have no reason to think they will. But I built my remote access on a WireGuard tunnel I control, and moving to something where a company I don't control holds the keys to my entire home network felt like a downgrade, even if the software is better.

I've also been burned recently enough that I'm not in a trusting mood. I wrote a whole angry post a few months ago about paying $100 a month for a service and getting less than 24 hours of notice before it changed underneath me. That was a paid tier. If that's what happens when I'm a customer, I'm not going to build my house on a free one.

So: I like the idea, I don't trust the arrangement. Which is exactly the situation self-hosting exists for.

Enter Headscale.

What Headscale actually is

Headscale is an open source implementation of the Tailscale control server. Your devices still run the official Tailscale client, they just point at your server instead of Tailscale's.

The important thing to understand is what the control server does and doesn't do. It handles key exchange, device registration, ACLs, and DNS settings. It does not sit in the middle of your traffic. Once two devices know about each other, they talk directly. So Headscale being a small container on a cheap VPS is completely fine.

I put it on the same Hetzner box that was already running WireGuard, because it already has a public IP and I was going to be deleting the WireGuard side anyway.

The Docker Compose setup

Headscale is CLI-first, which is fine, but I got tired of typing docker exec headscale headscale ... within about four minutes. So I also added Headplane, a web UI for it.

Directory structure first:

mkdir -p ~/headscale/config/{headscale,headplane}
cd ~/headscale
wget -O config/headscale/config.yaml https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml
wget -O config/headplane/config.yaml https://raw.githubusercontent.com/tale/headplane/main/config.example.yaml

And the compose file:

services:
 headplane:
 image: ghcr.io/tale/headplane:latest
 container_name: headplane
 restart: unless-stopped
 ports:
 - "3003:3000"
 volumes:
 - ./config/headplane/config.yaml:/etc/headplane/config.yaml
 - ./config/headplane/lib:/var/lib/headplane
 # Shared path to the Headscale config. This has to match
 # `headscale.config_path` in the Headplane config.
 - ./config/headscale/config.yaml:/etc/headscale/config.yaml
 - /var/run/docker.sock:/var/run/docker.sock:ro

 headscale:
 image: headscale/headscale:latest
 container_name: headscale
 restart: unless-stopped
 command: serve
 labels:
 # Absolutely necessary for Headplane to find Headscale.
 me.tale.headplane.target: headscale
 ports:
 - "8083:8080"
 volumes:
 # Same host path in both containers. This matters.
 - ./config/headscale/config.yaml:/etc/headscale/config.yaml
 - ./config/headscale/lib:/var/lib/headscale

Nginx handles TLS and public exposure, same as every other service on that box. If you're not putting a firewall in front of these, bind the ports to 127.0.0.1 instead ("127.0.0.1:8083:8080"), otherwise Docker happily opens them to the internet and walks around UFW while it's at it.

Note the me.tale.headplane.target label on the Headscale container. That's how Headplane finds it, and it's how Headplane restarts Headscale when you change DNS settings from the UI. Note also that both containers mount the Headscale config from the same host path. Headplane reads it directly, so if the paths drift you get a UI that shows you stale settings.

Headscale config

The parts of config/headscale/config.yaml that matter:

server_url: https://headscale.example.com
listen_addr: 0.0.0.0:8080
metrics_listen_addr: 127.0.0.1:9090

database:
 type: sqlite3
 sqlite:
 path: /var/lib/headscale/db.sqlite

dns:
 magic_dns: true
 base_domain: ts.example.com
 override_local_dns: true
 nameservers:
 global:
 - 1.1.1.1

Leave nameservers.global pointing at a public resolver for now. We'll swap it for the Pi-hole later, once the Pi-hole has joined the network and has an address to point at.

base_domain has to be different from your server_url domain, otherwise Headscale refuses to start.

Headplane config

In config/headplane/config.yaml:

server:
 host: "0.0.0.0"
 port: 3000
 base_url: "https://headplane.example.com"
 cookie_secret: "<32 char random string>"
 cookie_secure: true
 data_path: "/var/lib/headplane"

headscale:
 url: "http://headscale:8080"
 config_path: "/etc/headscale/config.yaml"
 api_key: ""

Generate the cookie secret with openssl rand -hex 32.

The url is the internal Docker address: container name, container port. Not whatever port you mapped on the host. The two containers talk over the compose network.

Then start Headscale on its own, create a user and an API key:

docker compose up -d headscale
docker exec headscale headscale users create myuser
docker exec headscale headscale apikeys create --expiration 90d

Paste that key into api_key and bring up Headplane. The key is only shown once, so if you lose it, just make another one. apikeys list only shows the prefix.

Nginx

Two vhosts, nothing exotic. But the Headscale one needs WebSocket passthrough, and this is the first place I lost time (more on that below):

location / {
 proxy_pass http://127.0.0.1:8083;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto https;
 proxy_redirect off;
 proxy_read_timeout 5m;
}

Headplane is a boring proxy block, no special headers needed. Certbot for certs, as usual.

Pi-hole as the tailnet DNS

This is my favourite part of the whole setup, and the reason I bothered.

Join your home Pi-hole to the network like any other device:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com
tailscale ip -4

Take that 100.x.x.x address, put it in Headscale's dns.nameservers.global, and restart the container.

Now every device on the tailnet uses my home Pi-hole for all DNS. Which means:

Neither of those is new, I had both with the old WireGuard setup. The difference is that I now get them from one Pi-hole instead of two, and I didn't have to think about it. The Pi-hole joined the tailnet, I pointed Headscale at it, and every device I add from now on inherits both for free.

override_local_dns: true is what forces this. Without it, your phone keeps using whatever DNS the carrier hands it, the tunnel works fine, and your internal domains silently fail to resolve.

The subnet router

A mesh VPN only connects the devices that are on it. My printer can't run a Tailscale client. Neither can most of the stuff I care about.

The fix is a subnet router: one device on your LAN that advertises the whole network to everyone else. I used the Pi-hole box, since it was already joined:

sudo tailscale up --login-server https://headscale.example.com \
 --advertise-routes=192.168.0.0/24

Two things have to happen after this or nothing works, and I hit both.

First, IP forwarding:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Second, and this is the one that got me: routes are double opt-in. The node advertises, and then the control server has to approve. Advertising alone does nothing.

docker exec headscale headscale nodes list-routes
docker exec headscale headscale nodes approve-routes --identifier 1 --routes 192.168.0.0/24

The moment I ran that second command, everything worked. Printer, internal domains, random machines on my LAN, all reachable from my phone on cellular.

Clients

You don't need a special app. The official Tailscale clients all support custom control servers.

On Android, install from Play Store or F-Droid, go to "Accounts", tap the kebab menu, and select "Use an alternate server". Enter your Headscale URL and log in.

On iOS it's slightly more buried: install from the App Store, tap the account icon, "Log in", then use the options menu to pick "Use custom coordination server".

macOS is the one with a real trap. Use the standalone build, not the Mac App Store one, because the App Store version is sandboxed and fights you on custom control servers. brew install tailscale works, or grab the standalone package from Tailscale's download page. Then:

sudo tailscale up --login-server https://headscale.example.com
tailscale set --accept-routes

That --accept-routes is easy to forget. Without it the client joins fine and then can't see anything on your LAN.

The gotchas that cost me the most time

Four things ate most of my afternoon. All of them had error messages that pointed somewhere other than the actual problem.

Headscale listening on 127.0.0.1 inside its own container

Headplane kept logging this:

Error while validating API key: [object Object]

I regenerated that API key three times. The key was fine. The real problem was one line above in the Headscale logs:

INF listening and serving HTTP on: 127.0.0.1:8080

127.0.0.1 inside a container means that container only. Not the compose network, not the other container sitting right next to it. Headplane literally could not open a connection, so it couldn't validate anything, and reported that as an auth failure.

Set listen_addr: 0.0.0.0:8080 in the Headscale config. Your host port mapping is a separate concern and keeps working the same.

Nginx eating the WebSocket upgrade

Clients wouldn't connect, and Headscale said:

WRN no upgrade header in TS2021 request. If headscale is behind a reverse proxy,
make sure it is configured to pass WebSockets through.

At least this error tells you exactly what's wrong. My nginx config was a copy-paste of the same reverse proxy block I use for every other service on that box, which has no Upgrade handling because nothing else needs it.

The commonly recommended fix uses a map block in the http context:

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
}

The idea is that plain HTTP requests to the same vhost get Connection: close instead of a bogus Connection: upgrade. If you put that map somewhere nginx doesn't load it into the http context, you get unknown "connection_upgrade" variable and nothing starts.

I'll be honest: I got that error, commented the Connection line out entirely to keep moving, and it worked. It's on my list to go back and do properly, because "it worked when I removed the correctness" is not a state I enjoy leaving things in.

The routes CLI moved

Every guide and blog post out there tells you to run:

headscale routes list
headscale routes enable -r 1

On 0.29 that gives you unknown command "routes". It's now under nodes:

headscale nodes list-routes
headscale nodes approve-routes --identifier 1 --routes 192.168.0.0/24

Related: --user wants a numeric ID now, not a username. headscale users list gives you the number.

When in doubt, headscale --help is more current than anything you'll find in a search result. I lost a few minutes to blog posts written against older versions before I just asked the binary.

Pi-hole ignoring the tailnet

Tunnel up, subnet routes approved, ping 1.1.1.1 working, and google.com resolving to nothing.

Pi-hole's default interface listening behaviour doesn't answer queries arriving on the tailscale0 interface. Settings, then DNS, then set it to listen on all interfaces and permit all origins. Or scope it to the tailnet CIDR if you want to be tidier about it than I was.

The bash alias

Small thing, big quality of life improvement:

alias headscale='docker exec headscale headscale'

Now every command in every tutorial you find online works verbatim, without mentally prefixing the docker part every time. Just remember it's there if you ever install the real binary on the same box, or you'll spend an entertaining twenty minutes wondering why the local install ignores your config file.

What I still need to do

I'm not going to pretend this is finished.

The old WireGuard tunnel and its dedicated Pi-hole are still running. Headscale does everything they did, but I'm leaving them up until I've gone through the Nginx Proxy Manager config and confirmed nothing still points at a 10.0.0.x address. Deleting infrastructure at 2 AM after a successful afternoon is how you learn what depended on it.

Was it worth it?

Yes, and for reasons beyond the printer.

The setup collapsed two Pi-holes and two IP ranges into one mental model. My phone now behaves identically at home and on cellular. Every internal service I add from now on works remotely for free, without port forwarding or a new proxy host or any thought about which side of a tunnel it lives on.

And no ports are open to my LAN. The only publicly reachable thing is the Headscale control server, which hands out keys and doesn't carry traffic.

The total cost was one afternoon, most of which was spent on four error messages that pointed at the wrong thing. Hopefully this post saves you those.

If you want to check the printer thing specifically: Bambu printers in LAN-only mode expose MQTT on 8883 and FTPS on 990. There's no web UI, so don't waste time typing the IP into a browser like I did. Once you're on the tailnet, OctoApp just takes the same local IP and access code you use at home.

See you in the next one!

03 Aug 2026 5:00am GMT

31 Jul 2026

feedDjango community aggregator: Community blog posts

Chicago Like a Local: Things to Do During DjangoCon US 2026 (Part 1)

DjangoCon US 2026 is coming back to Chicago from August 23-28, and we at Caktus couldn't be more thrilled, not only to be returning as a Silver Sponsor, but also because I (Keanya) have the privilege of chairing the conference once again!

31 Jul 2026 11:35pm GMT

Issue 348: One month until DjangoCon US

News

See You in Chicago in One Month!

In just one month, developers, maintainers, educators, and Django enthusiasts from around the world will gather in Chicago for DjangoCon US 2026.

DSF member of the month - Katherine "Kati" Michel

Kati is a longtime member of the Django community who has been a speaker, organizer of DjangoCon US, and member of DEFNA's board of directors. She shares some insightful thoughts on the current state of Django and where it can go from here, especially around AI.

Next Stop Pescara!

Looking forward to this year's Django on the Med 🏖️? Perhaps you should come? And what to do if you can't!

Updates to Django

Today, "Updates to Django" is presented by Raffaella from Djangonaut Space! 🚀

Last week we had 13 pull requests merged into Django by 10 different contributors - including 2 first-time contributors! Congratulations to Mundur and Philip Narteh for having their first commits merged into Django - welcome on board!

News in Django 6.2:

Django Fellow Reports

Django Fellow Report - Natalia

Focus this week was on the djangoproject.com email incident 📧🧱 and security work 🔐. I worked with Ops to diagnose and resolve the outage, addressing the source of abuse in the account registration flow. In parallel, I continued security reviews (including GeoDjango) and handled incoming reports 👁️. Overall brain ended up quite fried 🧠🍳😩.

Django Fellow Report - Sarah

Triaged a couple of interesting tickets, including one around paginator solutions. Reviewed four more and authored three. Also weighed in on the move to Playwright for integration testing and worked on six security reports.

And her baby boy now has his first two teeth.

Django Fellow Report - Jacob

Like last week, I focused almost all of my attention on improving our patches for the same two pending security reports. One reporter thanked us for our professional handling and brought a smile to my face when adding, "as I am sure you are getting completely slop cannoned all the way down." 🫟

More steady progress reviewing the GSoC work on expressions in SQL FROM clauses, too.

DjangoCon US

LAST DAY! 10% off + guaranteed t-shirt +swag ends July 31st)

Quick heads-up: today is the last day to save on DjangoCon US 2026 and the last day we can guarantee your t-shirt and tote bag for in-person registrations.

Articles

Setting Django's DEBUG safely

DEBUG=True does far more than turn on pretty error pages: it exposes stack traces and configuration to attackers, disables error reporting, degrades query performance, and serves unminified static files. A grep of Django's own source shows the setting changing behavior across more than two dozen files, which is the real argument for never letting production depend on it.

Nifty Django Feature: setUpTestData

setUpTestData() runs once per test class where setUp() runs again for every test method, so moving shared fixtures into it cuts repeated create and destroy work off your suite. A short Pet and Species example makes the difference concrete: the species row is built once for the whole class, while anything created in setUp is rebuilt for each test.

Django: release code words up to 6.1

Every Django release announcement hides a "code word" introducing the new features, and this post tables them all from 1.7 through 6.1, each linked to its Wiktionary definition and scored for rarity using the wordfreq package. Carlton's mezcla (3.2) wins on obscurity by not appearing in the English frequency data at all, while Sarah's composite (5.2) was a wink at that release's composite primary keys.

Python: spy on function calls with unittest.mock's wraps

Despite the name, unittest.mock builds spies as well as mocks: pass wraps and calls fall through to the real function and return real results, while the mock still records them for assertions. A caching example checks that compute_owl_sound() runs only once across two owl_sound() calls, and pairs it with autospec=True, which is optional when spying on functions but required for methods.

Python: inspect interleaved unittest.mock calls with attached mocks

To assert the order of calls across several mocks, attach them to a parent so its mock_calls records everything on one interleaved timeline. Methods attach themselves when you build the parent with create_autospec(Kettle, instance=True), while separate module-level functions need an explicit attach_mock() before you can check the whole sequence in a single assertion.

Podcasts

Talk Python #556: Updates on Django's Async Story - Carlton Gibson

Carlton answers all your questions on Django, async, what to be excited about in Django 6.1, and more. Well worth the full listen.

Sponsored

It's hard to ask to meet a stranger

So I'll go first. I'm Tim Schilling. I enjoy talking to people about software, Django and career development. I recently pivoted to specifically focus on helping others in their careers. If you could use some support, or just want to talk with me, set up a call with me!

Videos

No More Spreadsheets! Building PyLadiesCon Infrastructure with Python and Django - Mariatta

From PyCon US, Mariatta outlines how PyLadies said no to spreadsheets and instead started building out its own conference infrastructure using Python and Django.

Django Job Board

Two new listings lead the board this week: a one-year Security Developer role at the Python Software Foundation covering CPython vulnerabilities and PyPI malware, plus senior full-stack work at Hive Collective, with Django roles at MyOme and Fusionbox still open.

Security Developer at Python Software Foundation 🆕

Senior Full Stack Engineer at Hive Collective 🆕

Senior Backend Engineer at MyOme

Python + TypeScript Engineers at Fusionbox

Projects

Spwig/commerce

Spwig is a full-stack, self-hosted e-commerce platform on Django 5, now open source under AGPL-3.0. Server-rendered storefront, admin, REST API, POS, and page builder in a single modular monolith.

31 Jul 2026 3:00pm GMT

28 Jul 2026

feedDjango community aggregator: Community blog posts

Fast enough

Efficient resource utilization was at the forefront of computing from the very beginning. Over time we traded some of that efficiency for developer experience, and preserved the rest by harnessing better hardware and new paradigms: multithreading and multiprocessing, stream processing , asynchronous programming… Languages are how we reason about problems, encode algorithms, and organize programs - the vector runs from high-level languages through structured programming , OOP , functional and logic programming . Note what that vector does not include: how the runtime is structured, compiled or interpreted - either way we write some text and hand it to the system. Each step looks logical in hindsight. Yet some things don't look logical at all.

Fast enough

28 Jul 2026 10:00am GMT

24 Jul 2026

feedDjango community aggregator: Community blog posts

Issue 347: Django 6.1 release candidate 1 released

News

Django 6.1 release candidate 1 released

This is the final opportunity to try out the new version before Django 6.1 is released. Try it, run your test suite, and report anything that breaks!

The DjangoCon US 2026 schedule has been released!

The talk lineup is out, covering Django 6.0 and 6.1 features, modern deployment patterns, GeoDjango at scale, and lightning talks across all three days.

PyPI Releases now reject new files after 14 days

PyPI will reject new files uploaded to releases older than 14 days to limit the impact of compromised publishing tokens or workflows.

Planned Updates to the PyPI User Interface

PyPI's first UI refresh since 2018 will roll out in phases over the coming months, surfacing more security signals on package pages. The first phase is staged on TestPyPI now and ready for your feedback.

Wagtail CMS News

What our AI guiding principles actually mean

Wagtail unpacks its refreshed AI guiding principles and how they steer adoption in practice, starting with a firm commitment: no AI dependency in Wagtail core, with AI features staying opt-in through packages like Wagtail AI.

Django Software Foundation

DSF Board monthly meeting, July 09, 2026

Minutes from this month's DSF Board meeting: a host for DjangoCon Europe 2027 was approved, a new Google Summer of Code Working Group was chartered, Executive Director hiring continues with guidance from the PSF, and grants went to PyCon Cameroon and PyCon Africa.

Updates to Django

Today, "Updates to Django" is presented by Raffaella from Djangonaut Space! 🚀

Last week we had 17 pull requests merged into Django by 11 different contributors - including 6 first-time contributors! Congratulations to Tom Most, CharulL00, Sina Chaichi Maleki, Harvey Bellini, Stephanie and Vismay for having their first commits merged into Django - welcome on board!

News in Django 6.2:

Thanks to the continuous efforts of the contributors, a SQLite regression test has also been added to inspectdb when a table has a foreign key that references sqlite_master. (#25243)

Support for prefers-color-scheme was also implemented, adding dark mode CSS overrides for the technical 500 (traceback) and 404 debug views. (#35875)

Django Fellow Reports

Django Fellow Report - Natalia

A security-heavy week: two patches for confirmed vulnerabilities, deep-dive reviews of two more, and prep for the August release with CVE metadata and prenotifications, plus continued iteration on EmailValidator improvements.

Django Fellow Report - Sarah

Reviews across Django and djangoproject.com, including the Selenium to Playwright migration and admin widget fixes, plus a new GitHub Action to test djangoproject.com against Django main and engagement on six security issues across Django and djangoproject.com.

Django Fellow Report - Jacob

Sustained attention on a couple of security reports, alongside triage and a long review list covering dark mode error pages, Oracle Test Pilot in CI, and the asgiref 3.12 update that enables free-threading tests.

Python Software Foundation

Get Ready: PSF Board Nominations Opening Soon!

PSF Board nominations open July 28, with voting September 1-15. If you're a voting member, affirm your intent to vote by August 25.

Get Ready: 2026 Python Packaging Council Nominations Opening Soon!

Nominations for the first-ever Python Packaging Council open July 28 and close August 11.

Events

Django Girls Chicago - August 22, 2026

Django Girls returns the Saturday before DjangoCon US in Chicago: build your first website, eat free food, and meet fellow aspiring Django developers. The free workshop is limited to 45 people and applications close August 12, so apply early.

Preparing for sprints as a project leader (at DjangoCon US)

As DjangoCon US approaches in just a few weeks time, here are some good tips on how to make the most out of the sprints following the tutorial talks.

A First-Timer's Guide to Navigating America

If you are attending DjangoCon US, please do follow the news section of the website, as it has helpful articles like this one, as well as info on childcare at the conference, and more.

Sponsored Link

When is it worth paying for a mentor?

Thinking about hiring a mentor to grow as a Django developer? Here are a few honest questions to help you get clarity on whether now's the right time.

Articles

Django: introducing django-crawl

Adam Johnson introduces django-crawl, a new package that crawls your whole site with Django's test client (via links, sitemaps, or a Python API) to surface broken pages before your users do.

Nifty Django Feature: Form Templates

Django's form templates separate a form's HTML from the view that processes it: set template_name on the form for one reusable layout, or on an individual field when a single input needs custom markup.

Some more things about Django I've been enjoying

Building a "2010 style" backend-heavy web app, this writeup highlights Django's readable query builders, handy template filters like querystring and json_script, and the comfort of automatic migrations. It also covers the author's practical performance questions, including a misconfigured cached template loader and why it mattered.

Browser Push Notifications for a Django Website

A step-by-step tutorial on adding browser Web Push notifications to a Django site using VAPID keys, a service worker, and a Huey background task, so you get OS-level notifications even when the admin tab is closed.

Is it time to go back to Django?

Some arguments for Django's opinionated, batteries-included approach in the AI-coding era, since it limits the decisions an AI agent has to make and reduces the chance of it going astray.

Deploying Web Apps in 2026: My EuroPython Conference Talk

The written version of Will Vincent's EuroPython talk, which maps today's hosting landscape and builds a ten-step mental model of everything your dev server quietly handles for you, from WSGI servers and static files to running migrations at release time.

My EuroPython 2026 - Paolo Melchiorre

A day-by-day recap of Paolo Melchiorre's EuroPython 2026 in Kraków, compiled from Mastodon posts and photos, from the Python Steering Council update to rethinking asyncio for free-threaded Python and time with the Django community at the booth.

EuroPython 2026 Recap - Will Vincent

Highlights from a packed week in Kraków, where the standout theme was agentic AI workflows, with teams split between off-the-shelf tools and heavy internal tooling.

PyCon US 2026 Recap - Katherine Michel

Katherine's famous PyCon recap is here! Security and AI front and center, PSF and PyPI updates, steering council priorities for free-threading, and lots of great pictures.

Events

Django on the Med

Three days of Django development sprints, September 23-25 in Pescara, Italy. The second edition is free to attend and gathers Fellows, board and Steering Council members, and contributors new and experienced to push Django forward.

Django Day Copenhagen 2026

October 2 in Copenhagen. The first three talks are by Marijke Luttekes, Efe Öge, and Denny Biasiolli.

Django Job Board

Three new remote openings join the board this week, from AI-native full-stack work at Hive Collective to Django backend engineering for genetic testing at MyOme and Python + TypeScript roles at Fusionbox.

Senior Full Stack Engineer at Hive Collective 🆕

Senior Backend Engineer at MyOme 🆕

Python + TypeScript Engineers at Fusionbox 🆕

Freelance Full-Stack Web App Developer at Mindrift

Projects

adamchainz/django-crawl

An in-process site crawler using Django's test client.

FROWNINGdev/django-orm-lens

See your entire Django schema (every model, field, and relationship) in your editor, terminal, or AI agent, one keystroke away from a live ER diagram.

24 Jul 2026 3:00pm GMT

Django: release code words up to 6.1

Did you know that each Django release has a "code word" associated with it? It's hidden in plain sight, in the announcement blog post describing the list of features coming in the next version. I think this is a lovely little tradition.

I last covered the list back in 2021, for Django 3.2 (post). This post expands the table up until Django 6.1, which is expected next month (the first release candidate came out earlier this week).

Each code word links to its Wiktionary entry so you can see the definition. The word frequency column is based on the English data in the wordfreq Python package, as occurrences per billion words, so higher numbers mean the word is more common.

Version Post author Quote with code word highlighted Word frequency
(per billion words)
1.7 James Bennett ...will bring several major new features to Django, along with a host of other improvements... 58,900
1.8 Tim Graham ...several major new features and a cornucopia of other improvements... 363
1.9 Tim Graham ... myriad of goodies... 3,090
1.10 Tim Graham ... panoply of new features... 209
1.11 Tim Graham ... medley of new features... 1,910
2.0 Tim Graham ... assortment of new features... 1,820
2.1 Tim Graham ... smorgasbord of new features... 263
2.2 Carlton Gibson ... salmagundi of new features... 36
3.0 Carlton Gibson ... raft of new features... 2,880
3.1 Mariusz Felisiak ... potpourri of new features... 245
3.2 Carlton Gibson ... mezcla of new features... N/A (not in English data)
4.0 Mariusz Felisiak ... abundance of new features... 7,240
4.1 Carlton Gibson ... profusion of new features... 331
4.2 Mariusz Felisiak ... farrago of new features... 83
5.0 Natalia Bidart ... deluge of exciting new features... 1,120
5.1 Natalia Bidart ... kaleidoscope of improvements... 692
5.2 Sarah Boyce ... composite of new features... 8,710
6.0 Natalia Bidart ...assembles a mosaic of modern tools and thoughtful design... 3,800
6.1 Jacob Walls ...a harmonious mélange of new features... 98

Some observations on the newer entries:

Fin

May you enjoy Django's ever-growing omnium-gatherum of features,

-Adam

24 Jul 2026 4:00am GMT

22 Jul 2026

feedDjango community aggregator: Community blog posts

Tracking Blips

bliptracker was a side project that I happened to produce during June and last week realised I hadn't written about it here, so here goes!

One annoyance I have with Claude.ai (or other web based LLM interfaces), is that I would start multiple conversations across multiple topics such as client work, organising my Todoist, an idea to explore, gifts to research, the list goes on, but I was keeping open tabs for each conversation to not lose track of the active conversations, but this didn't work as I still had those open loops in my head to follow up to move each conversation forwards.

I didn't want a full blown task manager (I pay for Todoist which fits perfectly), but I did want to track the state of each conversation in Claude from both the web app and the mobile. The result is a two fold solution, first there is a system prompt telling Claude to end each respond with either a 🔴, along with the next action required from me, or a ✅ which tells me the conversation is resolved. The second part of the solution is a Chrome extension which then automatically updates the title of any conversation with the red dot or green check mark, so I can tell at a glance which chats need work and which are done.

I do have a couple more features planned such as supporting other LLMs and a possible snooze feature. But for now it's a small working project that keeps my chats organised. It's available at bliptracker.xyz.

One final point on this project, I hope that eventually it gets replace by Anthropic building a better native product for tracking the status of chats, it's very limited right now. More widely this highlights that while new models are powerful and can do more, it still requires us as engineers to build products that solve actual problems in novel, tasteful and well designed solutions. That is what we pay for when buy a tool and what our users expect from us and something that no model as far as I can see will ever replace.

22 Jul 2026 5:00am GMT

Django: introducing django-crawl

I recently migrated one of my client projects from the legacy django-csp package to Django 6.0's built-in Content Security Policy (CSP) support (release note). This security header is a powerful tool for preventing unwanted content from being loaded on your site, so configuration correctness is paramount. The migration was fairly straightforward, but a few pages had complicated overrides, so I wanted to be sure that no CSP headers had been changed by my swapping of CSP implementations.

I had the idea to verify no page had changed its content-security-policy header by crawling the site with Django's test client, outputting URL and header contents during the process. By diffing the output from crawls before and after the migration, I could check for changes and track down which pages had been affected.

The core loop of that script looked something like this:

from collections import deque
from django.test import Client


client = Client()
client.force_login(superuser)

queue: deque[str] = deque(["/", "/admin/"])
...

while queue:
    url = queue.popleft()
    ...
    response = client.get(url, follow=False)
    ...
    print(f"{url}\t{response.headers.get('content-security-policy')}")
    ...
    for anchor in BeautifulSoup(response.content, "html.parser").find_all(
        "a", href=True
    ):
        # Enqueue these found links
        ...

This simple crawl of the site ended up flushing out seven non-CSP bugs, despite the project having 100% test coverage and a full suite of integration tests. Those bugs were due to incorrect link generation, admin features not being disabled, and regular old broken code.

I was pretty impressed with the power of this technique for finding broken stuff! Given this experience, I wanted to expand the script into a reusable tool, which I have now done with django-crawl.

To use django-crawl, install it, add it to INSTALLED_APPS, and you can run the crawl management command:

$ ./manage.py crawl -v 2
🐛 Crawling up to 1000 URLs, logged in as Ad Min
/
/about/
/blog/
/contact/
/dev/
/blog/2026/
/blog/2025/
/blog/2026/07/22/introducing-django-crawl/
...
🦋 Crawled 1000 URLs, encountered 0 errors, stopped due to reaching max URL limit of 1000.

The command reports any errors it encounters, from broken links to exceptions. The output uses Rich for pretty formatting and a live spinner while it runs. Adding -v 2 prints the URLs as they are crawled.

The crawler discovers links in various forms in HTML responses (<a href>, <link href>, <script src>, <img src>, etc.), sitemaps, and feeds. If you have a sitemap, you can start your crawl with a simple:

$ ./manage.py crawl /sitemap.xml

The HTML parsing is done with a custom Rust extension built with html5ever, the HTML parser from the Servo project, so it's very fast. And with no overhead from real HTTP requests or inter-process communication, the crawl is limited only by how fast your application code can run.

django-crawl also provides a Python API that you can use to make a mega-test that crawls your whole site with example data, raising an ExceptionGroup if any errors are encountered:

from django.contrib.auth.models import User
from django.test import TestCase

import django_crawl


class CrawlTests(TestCase):
    @classmethod
    def setUpTestData(cls):
        cls.admin = User.objects.create_superuser(username="admin")

    def test_crawl(self):
        client = django_crawl.CrawlClient()
        client.force_login(self.admin)
        django_crawl.crawl("/", "/admin/", client=client)

I am not sure if this is a good fit for most projects, since it will leave you with one long test that exercises many views. But it might be good for building a "safety net" on untested projects, something I know Jeff Triplett likes to do (ref Django Chat #24).

Fin

Please try out django-crawl today and let me know how it goes.

May your site not slow to a crawl,

-Adam

22 Jul 2026 4:00am GMT

21 Jul 2026

feedDjango community aggregator: Community blog posts

EuroPython 2026 Recap

Seven days of sponsor booth, talks, sprints, and hallway chats.

21 Jul 2026 11:56am GMT

Loop and `if` invariants

We spend a lot of effort making code run and almost none making it argue. An invariant is the cheap proof tool that turns "I think this loop is right" into "I know it is" - and we already use them without naming them.

Loop and if invariants

21 Jul 2026 11:00am GMT