Best Django Hosting in 2026: Your App Isn't What Costs You
Django is small. We built a stock Django 5.1 project, ran it under gunicorn in Docker, and watched the memory:
| Setup | Memory |
|---|---|
| gunicorn, 1 worker | 47.97 MB |
| gunicorn, 2 workers | 73.51 MB |
| gunicorn, 3 workers | 99.87 MB |
| gunicorn, 4 workers | 128.1 MB |
| uvicorn (ASGI), 1 worker | 37.53 MB |
That’s roughly 21MB of master process plus about 26MB per worker, and it’s remarkably linear. A four-worker Django app fits in 128MB.
So sizing your server for Django is the wrong exercise. On a 4GB box your application uses about 3% of the RAM. The money goes somewhere else entirely — and it’s usually the database.
The same holds for other frameworks — we measured Laravel at 58.7MB, and 89.7MB with a queue worker, which is the identical story with a different runtime.
The cost nobody puts in the comparison
From DigitalOcean’s own PostgreSQL pricing documentation:
”Single node clusters begin at $15.00 per month for a single node cluster with 1 GiB of RAM. Single node clusters are not highly available… We recommend these clusters for preliminary development and testing.”
”High availability clusters begin at $30.00 per month for a 2 GiB RAM / 1 vCPU primary node with at least one standby.”
Now put that next to the server. A 4GB DigitalOcean droplet is $24/month and runs your entire Django application in 128MB.
| Component | Cost | RAM |
|---|---|---|
| 4GB droplet (runs the whole app) | $24.00 | 4 GB |
| Managed Postgres, single node | $15.00 | 1 GB |
| Managed Postgres, HA (production) | $30.00 | 2 GB |
The production-tier database costs more than the server running your application, for half the memory. And by DigitalOcean’s own wording, the $15 tier is the one it recommends for development and testing — so the honest production comparison is the $30 one.
Additional storage is $0.21 per GiB per month on top.
This is the decision that actually determines your bill, and almost no Django hosting comparison mentions it. You can run Postgres on the same droplet for nothing, in the ~3.8GB your app isn’t using. What you give up is automated backups, failover and patching — a real trade, but make it deliberately rather than by accident.
Where shared hosting breaks
Three things a real Django app does that shared plans generally can’t:
1. A persistent WSGI/ASGI process. Shared hosting runs code per request. Django needs gunicorn or uvicorn resident, holding your application in memory.
2. Celery workers. A background worker is a second long-running process with its own memory — and it’s the component that actually consumes RAM, because it’s running your slow jobs. Budget for it separately; it isn’t free the way the web workers nearly are.
3. Channels and WebSockets. Async Django with Channels needs ASGI, not WSGI, plus a channel layer — usually Redis. This changes the requirement completely, and it’s the case where “does this host support Python” is entirely the wrong question.
The test: if you can’t SSH in and run something under systemd or Docker that survives logout, you can’t run Django properly. That’s the same boundary that rules out Docker and n8n on shared plans.
WSGI or ASGI?
Use ASGI if you need WebSockets, Channels, server-sent events, or you’re calling slow external APIs where async views genuinely help. Our measurement showed uvicorn running lighter than gunicorn on a single process — 37.53MB against 47.97MB — though that’s one process against a master-plus-worker, not a like-for-like efficiency claim.
Use WSGI if you’re building a conventional request/response application, which is most of them. gunicorn with a few workers is boring, well-understood, and the memory cost is trivial at the numbers above.
You can run both, and many production Django deployments do: gunicorn for the ordinary views, uvicorn for the async ones.
The hosts
DigitalOcean — $24 for 4GB, best documentation in the category, per-second billing since January 2026, and the most granular status reporting of any provider here. The managed Postgres add-on is the thing to price carefully — $30/month for the HA tier, more than the droplet. Best choice if you want the managed database and accept its cost.
Railway — deploy from a repo with no server to manage, and Postgres provisioned alongside. It bills per second of resource residency, which suits a Django app that idles between requests better than it suits an always-busy worker — we compared that model against a flat VPS. The fastest path from git push to running app, at a premium.
Hetzner — the most RAM per euro, which matters once Celery and Postgres are on the same box. German entity and data centres. Two caveats: cloud instance availability has been limited since June, and backups exclude attached Volumes — the second one matters a lot if you put Postgres on a Volume, which is exactly what you’d do.
Hosting.com (formerly A2 Hosting) — long-standing Python support and a familiar cPanel-style environment. Confirm you’re getting a plan with root access and persistent processes, not a shared plan that merely has Python installed.
Hostinger — $11.99 renewal for 4GB, $14.99 for 8GB, one-click Docker templates, and refund terms that cover renewals. The cheapest sensible route to a Django VPS, and the 8GB tier is the one to buy if Postgres and Celery share the box.
UltaHost — $15.87 for 4GB with 3 vCPU, more cores than most at this price. Worth it if you’re running several gunicorn workers plus Celery, where cores matter more than gigabytes.
Cloudzy — $17.37 for 4GB billed monthly with no term, the low-commitment option for testing a deployment before choosing where it lives.
What we’d actually buy
One 8GB VPS running everything — gunicorn, Celery, Redis and Postgres — is the cheapest arrangement by a wide margin, and your app’s 128MB leaves plenty for the database. You own the backups and the patching.
Split it out when the database matters more than the money: when you need point-in-time recovery, automated failover, or you’d rather not be the person restoring a dump at 2am. That’s a $30/month decision, not a $5 one, and it’s worth making explicitly.
How we checked this
The memory figures are ours, measured on 23 August 2026. We built a container with Python 3.12 and Django 5.1, created a stock project with django-admin startproject, served it with gunicorn at one to four workers and with uvicorn at one, warmed each with 30 requests, and read the container’s memory from docker stats.
Read those numbers for what they are: a stock project with no application code. A real Django app loads your models, your dependencies, your ORM query results and whatever else you import — a production app will use substantially more than 48MB per worker. What the measurement establishes reliably is the shape: a roughly fixed master process plus a near-constant per-worker increment, on a base that is small. Do not size your production server from our absolute numbers; measure your own app the same way.
The uvicorn comparison is not like-for-like. We ran a single uvicorn process against gunicorn’s master-plus-worker, so the 37.53MB against 47.97MB difference partly reflects process structure rather than ASGI being inherently lighter. We did not benchmark throughput, latency or async behaviour at all.
The database pricing is quoted verbatim from DigitalOcean’s PostgreSQL pricing documentation, read the same day — the $15.00 single-node entry with 1 GiB, its own recommendation of that tier “for preliminary development and testing”, the $30.00 high-availability entry at 2 GiB with a standby, and $0.21 per GiB for additional storage. DigitalOcean’s page carries its own “last verified” date of 17 June 2025, so check current figures before budgeting.
We priced one provider’s managed database, not seven. The comparison in this article is DigitalOcean’s droplet against DigitalOcean’s own database, which is a fair internal comparison and not a survey of managed Postgres pricing. Other providers differ, and we haven’t checked them.
The provider prices other than DigitalOcean’s are figures established across this series rather than re-verified today. We have not verified Hosting.com’s current Python plan structure at all, which is why our note on it is a caution rather than a recommendation.
The shared-hosting limitations are architectural reasoning, not tests. We did not attempt a Django deployment on any shared plan.
What we did not do: deploy a real Django application anywhere, run Celery or Channels, configure a channel layer, benchmark any host, or test a managed database.
The host links above are affiliate links. The article’s cheapest recommendation — run Postgres on the same box you already pay for — removes a $30/month line item we’d otherwise earn from.
FAQ
How much RAM does a Django app need?
Less than people assume. We measured a stock Django 5.1 project at 48MB under gunicorn with one worker and 128MB with four. Your real app will use more, but the base is small — size for your database and background workers instead.
What’s the best hosting for Django?
A VPS with root access, because Django needs a persistent WSGI or ASGI process. Shared hosting that merely has Python installed generally can’t run it properly.
Can I run Django on shared hosting?
Usually not. Django needs a resident gunicorn or uvicorn process, and shared plans run code per request and reap long-running processes.
How much does managed Postgres cost?
On DigitalOcean, $15/month for a single 1 GiB node — which it recommends for development and testing — and $30/month for the high-availability tier, more than a 4GB droplet costs.
Should I use a managed database or run Postgres myself?
Running it on the same VPS is free and your app leaves plenty of room. Managed buys you backups, failover and patching. It’s a $30/month decision worth making deliberately.
Do I need ASGI for Django?
Only for WebSockets, Channels, server-sent events or genuinely async views. Conventional request/response apps are well served by gunicorn under WSGI.
What about Celery workers?
Budget for them separately — a Celery worker is another long-running process, and unlike your web workers it’s running your slow jobs, so it’s where the memory actually goes.
