07 Feb 2026
Django community aggregator: Community blog posts
It's time to leave Heroku
Back in the day Heroku felt like magic for small Django side projects. You pushed to main, it built and deployed automatically, and the free tier was generous enough that you could experiment without ever pulling out a credit card. For a long time, Heroku was the easiest way to get something live without worrying about servers, deployment scripts, or infrastructure at all. Every Python developer I knew recommended it.
Sadly, that era is over.
The slow decline
The problems started piling up in 2022. In April, hackers stole OAuth tokens used for GitHub integration, gaining access to customer repositories. It later emerged that hashed and salted customer passwords were also exfiltrated from an internal database. Heroku forced password resets for all users. Their handling of the incident was widely criticized: they revoked all GitHub integration tokens without warning, breaking deploys for everyone, and communication was slow and vague.
Then in August 2022, Heroku announced they would eliminate all free plans, blaming "fraud and abuse." By November, free dynos, free Postgres databases, and free Redis instances were all gone. Look, I understand this wasn't sustainable for the company. But they lost an entire generation of developers who had grown up with Heroku for their side projects and hobby apps. The same developers who would recommend Heroku at work. Going from free to a minimum of $5-7/month for a dyno plus $5/month for a database doesn't sound like much, but it adds up quickly when you have a few side projects, and it broke the frictionless experience that made Heroku special.
The platform also became unstable. On June 10, 2025, Heroku suffered a massive outage lasting over 15 hours. Dashboard, CLI, and many deployed applications were completely inoperable. Even their status page went down. Eight days later, another outage lasted 8.5 hours. Multiple smaller incidents followed throughout the rest of 2025, affecting SSL, login access, API performance, and logging. As one developer put it on Hacker News: "the last 5 years have been death by a thousand cuts."
And beyond the outages, Heroku simply stopped evolving. They never adopted Docker containers or Kubernetes. Yefim Natis of Gartner described it well: "I think they got frozen in time." Jason Warner, who led engineering at Heroku from 2014 to 2017, was even more blunt: "It started to calcify under Salesforce." No open source strategy, no modern container support, limited observability tooling. Heroku in 2026 runs essentially the same way it did in 2016.
Unsurprisingly, competitors sprung up to fill the void: Fly.io, Railway, Render, DigitalOcean App Platform, and self-hosted solutions like Coolify and Dokku. Developers were already leaving in droves.
The final nail
Yesterday, Heroku published a post titled An Update on Heroku, announcing they are transitioning to a "sustaining engineering model", "with an emphasis on maintaining quality and operational excellence rather than introducing new features." They also stopped offering enterprise contracts to new customers.
The reason? Salesforce (who acquired Heroku back in 2010) is "focusing its product and engineering investments on areas where it can deliver the greatest long-term customer value, including helping organizations build and deploy enterprise-grade AI." Translation: Heroku doesn't make enough money, and Salesforce would rather invest in AI hype.
Simon Willison called the announcement "ominous" and said he plans to migrate his blog off Heroku. A former Heroku product lead described years of underinvestment: "a starvation over a six-, seven-, eight-year period" where more apps and users were supported by fewer engineers.
This is the classic pattern: stop selling new contracts, honor existing ones, then eventually wind down. If you're still on Heroku, the writing is on the wall.
What leaving Heroku looks like
I want to share a concrete example. In 2023 I started working with Sound Radix, who had a SvelteKit app with a Django backend running on Heroku. They were paying $500 per month. Five hundred dollars for what is essentially an e-commerce website. And the performance was terrible: slow builds, sluggish website.
As one of my first tasks, I set up a Debian server on Hetzner and moved everything over. A single dedicated instance running the full stack. Cost: $75/month. Yes, setting up backups and auto-deploys on push took more work than Heroku's push-button experience. But we understood our stack from top to bottom, everything got significantly faster, and we were paying 85% less.
In 2025 we moved to Coolify, a self-hosted PaaS that gives you much of Heroku's developer experience without the lock-in or the price tag. We now run two Hetzner servers: a small $5/month instance for Coolify itself, and a $99/month server for the actual application (the $75/month instance was no longer offered by Hetzner). Setting up Coolify and getting a Django project running on it is really rather easy - I've written about it in detail: Running Django on Coolify and Django static and media files on Coolify.
Final thought
Heroku was genuinely great once. It pioneered the PaaS model and made deployment accessible to an entire generation of developers. But that was a long time ago. Between the security breaches, the death of the free tier, the outages, the technological stagnation, and now the explicit admission that no new features are coming - there's simply no reason to stay.
If you're still on Heroku, don't wait for the sunset announcement. Move now, while it's on your terms.
07 Feb 2026 6:22am GMT
06 Feb 2026
Django community aggregator: Community blog posts
Django News - Django security releases issued: 6.0.2, 5.2.11, and 4.2.28 - Feb 6th 2026
News
Django security releases issued: 6.0.2, 5.2.11, and 4.2.28
Django releases 6.0.2, 5.2.11, and 4.2.28 patch multiple security bugs, including PostGIS SQL injection, ASGI and Truncator denial of service, and timing and user enumeration.
Django Commons: We're recruiting new admins!
Django Commons is recruiting new admins to manage projects, membership, governance, and infrastructure; apply via the Admin Interest Form by March 16, 2026, AOE.
Recent trends in the work of the Django Security Team
Django Security Team sees many repeat vulnerability variations, leading to consistent patching and consideration of rearchitecting areas to reduce low-impact reports.
Releases
Django HealthCheck: Migration to v4.x
Update django-health-check to v4 by removing sub-apps and HEALTH_CHECK settings, reverting test model migration, and using HealthCheckView with explicit checks.
Python Insider: Python 3.14.3 and 3.13.12 are now available!
Python 3.14.3 (and 3.13.12) was released with deferred annotations, free-threaded support, improved async tooling, and other features that impact Django development and deployment.
Python Software Foundation
Your Python. Your Voice. Join the Python Developers Survey 2026!
This year marks the ninth iteration of the official Python Developers Survey.
Wagtail CMS News
An agent skill to upgrade your Wagtail site
Wagtail published an agent skill to plan and optionally perform safe, documentation-driven upgrades to new Wagtail releases while keeping a human in the loop.
Autosave is here in Wagtail 7.3 (and many other great things!)
Wagtail 7.3 adds StreamField block settings and ordering controls for cleaner custom block UIs, plus autosave, greener image defaults, accessibility rules, and docs in markdown.
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 2 first-time contributors! Congratulations to Jaffar Khan and Mark for having their first commits merged into Django - welcome on board!
- Fixed a regression in Django 6.0 where auto_now_add field values were not populated during
INSERToperations, due to incorrect parameters passed tofield.pre_save()(#36847). - Fixed a visual regression in Django 6.0 that caused the admin filter sidebar to wrap below the changelist when filter elements contained long text (#36850).
- Triaging tickets documentation is updated with a new "Reviewing patches" section, and the "Triage workflow" section is updated to invite more people to start the review process 🎉
Django Newsletter
Articles
Loopwerk: Django's test runner is underrated
Recommend Django's built-in test runner for predictable, minimal magic testing; use parameterized for inputs and switch to pytest only when required.
How to Switch to ty from Mypy
How to switch project type checking from mypy to Astral's ty, including installation, configuration via pyproject.toml, CI GitHub Actions, and pre-commit workarounds.
From Good Code to Reliable Software: A Practical Guide to Production-Ready Python Packages
Practical toolchain and workflows for making Python packages ready for production: reproducible installs, testing, linting, type checking, security scans, CI, and documentation.
Why light-weight websites may one day save your life
On the importance of light-weight websites on this bloated internet.
Why using [n] on a Django QuerySet can be unsafe?
Indexing a QuerySet can return nondeterministic rows because slicing does not add ordering, unlike first, which orders by primary key.
Docs or it's built differenlty - Priming AI with atomic docs
An opinionated approach to documentation so that it works for developers and AI alike.
Django Job Board
Three new backend gigs worth a click, from shipping REST APIs to going all-in on Django:
Python Developer REST APIs - Immediate Start at Worx-ai 🆕
Backend Software Developer at Chartwell Resource Group Ltd.
Senior Django Developer at SKYCATCHFIRE
Django Newsletter
Projects
nanorepublica/django-deadcode
A Django dead code analysis tool that tracks relationships between templates, URLs, and views to help identify and remove unused code.
FarhanAliRaza/django-hawkeye
Django BM25 full-text search using PostgreSQL - a lightweight Elasticsearch alternative.
Django (anti)patterns
A website and repo with 39 common antipatterns, listing them as well as suggested changes. Worth a look!
This RSS feed is published on https://django-news.com/. You can also subscribe via email.
06 Feb 2026 5:00pm GMT
02 Feb 2026
Django community aggregator: Community blog posts
ModelRenderers, a possible new component to Django...
Towards the end of last year I was working with form renderers in my startup to provide a consistent interface for forms across the project. I also used template partials to override widgets, delivering consistent rendering all in one file, a nice win. This made me wonder what other common components in a project get rendered to HTML that could benefit from a single, reusable place to avoid repeating myself.
Carlton's Neapolitan package already has this to some degree. There are two template tag types: one for object detail and one for object list. We also have FormRenderers in Django which already cascade from project down to an individual form, so perhaps we could apply the same logic to render models in a dry, configurable way rather than duplicating templates and logic. This made me wonder, could we have a python class whose role is to define how a model get's rendered? Let's be clear, we're not getting into serializers here and the validation or logic that comes with them, it's similar to the separation of Forms and FormRenders.
I'm thinking that this idea allows the rendering of an object of list of objects in a template like so:
{{ object }}
{{ object_list }}
This can be controlled via a class described above:
class MyModelRenderer(ModelRenderer):
list_template = ''
detail_template = ''
form_renderer = MyFormRenderer
The above class controls how a list of objects would be rendered along with a single object and the form renderer to use. The form side opens up the idea of chaining renderers together in order to find the correct template to use. This then links to the idea of having a template snippet for rendering related models. If you have a foreign key or a many-to-many relationship, your renderer could specify how to render itself as a related field. You could chain model renderers together so that, when rendering a related field, it looks up the appropriate snippet instead of rendering the entire detail or the entire list.
This obviously would be an optional API, but a potentially interesting one. It would certainly alter the look of a Django project and of course nothing stops you from rendering by hand. To me this leans into a different approach to having shared components at the template level, pushing towards not repeating yourself where possible.
Does this peak your interest or does this scream of nothing like Django at all? Let me know your thoughts!
02 Feb 2026 6:00am GMT