Django's Go-To Hosting List Now Says: Rent the Server, Run the Platform Yourself

On September 6, 2026, one commit re-sorted the page Django developers read when they ask where their app should live. The commit to wsvincent/awesome-django — the community's go-to curated Django list, with 11,247 stars — added two new sections under Hosting, Deployment Services and Self-Hosted Deployment, listed DeployHQ, Coolify, Dokploy, CapRover, and Kamal, and moved Appliku, Dokku, and Piku out of the PaaS section. The curator's reason, in the commit message itself: those tools "deploy to servers you rent rather than run the app themselves."

Read that sentence twice. The default advice a new Django team follows no longer assumes a platform runs your app for you. It assumes you rent the server and run the platform yourself — and treats that as a first-class answer, not a fallback for cheapskates.

Render, Railway, Fly, and Heroku are still listed. Nothing was deleted. But every new line points at owned servers, and that direction of travel is the story.

What the page says now, verbatim​

Before the commit, the Hosting section had two buckets: PaaS and IaaS. Dokku and Piku sat under PaaS, which was always a category error — they never ran anything for you; they turned your server into a Heroku lookalike. The commit fixed the taxonomy and expanded it:

Two things matter here beyond the names. First, the blurbs do real definitional work: "servers you rent elsewhere" versus "servers you own." The list now teaches every reader the distinction between who runs the app and who owns the machine — a distinction the old PaaS bucket blurred. Second, the self-hosted entries come with honest one-line positioning: Coolify and Dokploy are web-UI PaaSes with optional paid cloud control planes, CapRover is Docker Swarm-based, Kamal is SSH-and-Docker from Basecamp, Dokku is Heroku-style git push, Piku is the tiny single-server variant. A Django developer landing here gets a genuine menu, not a wink.

Why September 2026, not 2022​

Heroku killed its free tier in November 2022. If this were just about free dynos, the list would have re-sorted four years ago. Three things changed since, and together they explain the timing.

Heroku entered managed decline. In February 2026, Salesforce moved Heroku to a sustaining engineering model: no new features, no new enterprise contracts, maintenance patches only. The platform that taught a generation of Django developers git push heroku main is done adding features. For a framework ecosystem whose deployment folklore was written on Heroku buildpacks, that is not a pricing annoyance — it is the end of the default answer.

The managed middle got honest about its price. Render remains the most credible Heroku successor for Django, and it stays listed — but look at what staying costs. Render's free tier spins down and its free Postgres expires 30 days after creation; a small paid stack (web service plus Postgres) runs about $13/month, and a realistic setup with a worker lands around $20–30/month. That is fair value for managed infrastructure — and it is also a standing invitation to compare against the VPS column.

The self-hosted side grew up. Compare a typical production Django stack — web process, Celery worker, scheduler, Postgres, Redis:

The cost gap alone would not move a curated list. The adoption behind it does: Coolify sits near 58,000 GitHub stars with over 481,000 self-hosted instances reporting home, Dokploy gathered roughly 35,000 stars in about two years, Dokku holds ~32,000. These are not weekend projects anymore; they are the most-starred infrastructure a Django developer can install. When the curator needed entries for a new section, there was an embarrassment of maintained options — which is exactly what was missing in 2022.

Django is the third framework to do this​

The strongest evidence that this is an ecosystem-level shift, not one maintainer's taste, is that two other frameworks already made the same move in their own idiom.

Rails went furthest: Rails 8 ships Kamal 2 as the default deploy story — containers to your own servers over SSH with zero downtime, no Kubernetes required, straight from Basecamp's own production practice. The framework docs don't route you to a PaaS; they hand you a deploy.yml and assume a Linux box. Laravel's ecosystem centers on Forge (server provisioning you own) plus first-party Laravel Cloud, with community guides overwhelmingly written for the self-hosted path. In each case, the framework's own orbit teaches server-first deployment as the normal case.

Django's version is characteristically decentralized — there is no DHH to declare the default, so the default emerged in the awesome list instead. Note the Django-specific tell: Appliku, the one entry explicitly "Django-focused," deploys to your servers on DigitalOcean, Hetzner, AWS, or Linode. Even the bespoke Django tooling assumes you rent the machine. The pattern holds across all three ecosystems: the framework world now treats the PaaS as one option among several, and the owned-server path as the one worth documenting in detail.

That last clause is the part with teeth. Documentation effort follows the author's own stack. When the people writing Django deployment guides run Coolify on Hetzner or Kamal on a VPS, the guides a newcomer finds — the troubleshoot-this-error threads, the production-checklist gists, the "here is my complete deploy.yml" posts — are written for the self-hosted path first.

Managed-PaaS docs stay vendor-polished but community-thin. Over a few years, that compounds into a real moat: the easiest path to follow is the one with the most footsteps.

What changes for your next deploy​

Concretely, three branches, depending on where you stand:

Starting a new Django app? The default docs path now assumes an owned server. That means budgeting one Hetzner-class VPS and an afternoon with Coolify or Dokploy (web UI, managed-TLS-by-default) or Kamal (a YAML file and SSH keys) — instead of budgeting $20–140/month of PaaS from day one. Either choice in the new sections gets you git-push-to-deploy semantics; the difference is whether you also get a dashboard (Coolify/Dokploy/CapRover) or a CLI and a proxy (Kamal), and whether your database lives in a container on the same box or on managed Postgres elsewhere.

Still on Heroku? Plan the exit on the sustaining-mode timeline, not the panic timeline: the platform keeps running, but every month the ecosystem's new knowledge accrues elsewhere. And notice where your migration guides will come from — Appliku literally markets a leave-Heroku-for-a-server-you-own path, and the awesome list now files that path under its own heading. The migration guide Django developers actually read is being written by the self-hosting side first.

Staying managed? Render and Railway remain listed for good reason: managed Postgres with point-in-time recovery, zero-downtime deploys, and no 3 a.m. disk-full pages are worth real money. The honest tradeoff is cost-per-stack and control, not quality — just know that you're now swimming with the vendor docs while the community current flows the other way.

Whichever branch you take, name the ops you inherit before you commit. Self-hosting a Django stack means you own Postgres backups and restores (test the restore, not the backup), Redis persistence, TLS renewal (usually automated, until it isn't), OS patching, and the disk-full alert at 3 a.m. The awesome list's new sections hand you the deploy tools; they don't hand you a runbook. Budget a day to write yours — backup cron, restore drill, upgrade path — or the $130/month you saved on Heroku becomes the most expensive savings of your year.

The list is the canary​

Curated lists lag reality by design: a maintainer adds a section only after the thing is obviously, boringly real. That is what makes this commit worth more than its diff.

Somebody whose job is knowing what Django developers actually do looked at the landscape in September 2026 and concluded that where the app lives now has four answers, two of which assume you own the server. The managed PaaS didn't get removed. It got outnumbered.

The next Django developer who asks "where should I host this?" will land on that page, see four sections, and quite reasonably conclude that renting a server and running the platform yourself is simply what Django developers do now. Defaults are downstream of documentation. The documentation just moved.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.