What is the best Django hosting in 2026?
A Django app is a web process, a Postgres, somewhere to put media and usually a worker, so the answer turns on how many of those the platform hands you. Render has the friendliest free tier for a demo and charges $7/month for the smallest paid instance; Railway is $5/month plus usage and gets you to a working stack fastest; PythonAnywhere at $10/month is the gentlest first deploy if you have never shipped one.
Granite — our own platform — is $9/month with $15 of usage credits, and covers managed Postgres, a Valkey broker for Celery and S3-compatible media storage in one project. For a single stateless service with no uploads and no jobs, several cheaper options here beat it, and the table below says so.
Last updated 1 September 2026
Every platform below can run Django. That is not the interesting part, and it is where most hosting listicles stop. The interesting part is what happens around the WSGI process: where user uploads live so they survive a deploy, whether the Postgres is managed or something you are on call for, and whether you can run a Celery worker without renting a second server.
Django also costs meaningfully more to host than a compiled language. Each gunicorn worker is a full Python interpreter with your whole application loaded into it, so the memory floor is hundreds of megabytes rather than tens. The cheapest tiers that comfortably run a Go binary are uncomfortable here, and that shifts which providers are actually worth considering.
The short version: Render has the friendliest free tier for a demo, PythonAnywhere is the gentlest start if you have never deployed anything, Railway is the fastest way to a working stack, and Granite — our own platform — fits when Django needs Postgres, a Celery broker and somewhere to put media all at once. If your project is a single stateless service with no uploads and no background jobs, several of the cheaper options here beat us on price and we say so below.
How much does Django hosting cost?
| Provider | From /mo | Free tier | Managed DB | Persistent disk | Deploy from |
|---|---|---|---|---|---|
| Fly.io | ~$2 | Postgres (unmanaged app) | Dockerfile, buildpack | ||
| Railway | $5 | yes ($1 credits) | Git, Dockerfile, template | ||
| Render | $7 | yes (spins down) | Git, Dockerfile | ||
| Granite | $9 | from Advanced | Git, Docker image | ||
| PythonAnywhere | $10 | yes (limited) | MySQL | yes (5 GB) | Git pull, web UI |
| Koyeb | $29 | limited | Serverless Postgres | Git, Dockerfile | |
| Google Cloud Run | usage-based | yes (monthly allowance) | via Cloud SQL | no (use GCS) | Container image |
Entry prices as published by each provider on 1 September 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.
PaaS, serverless or a plain VPS?
A VPS is always cheaper per gigabyte, and with Django you need more gigabytes, so the gap looks larger than it does for other stacks. What a platform sells you is everything around gunicorn: TLS and its renewal, zero-downtime rollouts, log collection, and — the one that actually matters here — Postgres backups that someone else is responsible for restoring.
Serverless is a poor default for Django, and this is where it differs sharply from a compiled stack. Scale-to-zero assumes cheap cold starts; booting Python, importing Django and loading your app takes seconds, and a real visitor waits through it. It can still be the right answer for an internal tool that is idle most of the day — but you also have to move media to object storage first, because there is no disk.
A managed platform is where most production Django ends up, for one unglamorous reason: Django is rarely one process. As soon as there is a Celery worker, a beat scheduler and a database, the value is in having them in one place with one deploy, not in shaving a few dollars off the web tier.
There are uploads, a database and probably a Celery worker — the normal case
Managed platform
One deploy covers web, worker and beat, with Postgres and storage attached.
Granite · Railway · Render
Internal tool, idle most of the day, no uploads on local disk
Serverless
Free while idle, but users pay for the seconds-long cold start.
Cloud Run · Koyeb
First deployment ever, or you want to own the whole machine
PythonAnywhere or a VPS
Simplest possible start, or full control and the lowest price per gigabyte.
PythonAnywhere · Hetzner · DigitalOcean
What does each platform actually give you?
Fly.io
- Best for
- Teams comfortable operating their own database, who want multiple regions and per-second billing.
- Pricing
- Pay as you go. The smallest shared-cpu-1x machine with 256 MB RAM works out at roughly $2.02/month, billed per second.
- Multi-region deployment and Anycast routing are first-class, which matters for a latency-sensitive app.
- Per-second billing and volumes are available on every machine.
- Takes your Dockerfile as-is, so a slim multi-stage Python image works exactly as intended.
- Postgres is a Fly app you operate and back up yourself — a footnote for a stateless service, a real commitment for Django, where the database is the application.
- The ~$2 machine that suits a Go binary has 256 MB of RAM; a gunicorn worker set needs several times that, so Fly's headline price does not apply to this stack.
- No free tier for new organisations since October 2024.
Railway
- Best for
- Getting Django, Postgres and Redis running together in an afternoon.
- Pricing
- Billing is per second of actual usage against a monthly minimum: $5 on Hobby and $20 on Pro, each including that much usage credit. The free plan is a 30-day trial with $5 of credits and $1 a month afterwards, capped at 1 vCPU and 0.5 GB per service. Pro includes unlimited workspace seats.
- Templates cover the whole Django stack, including Postgres and a Redis for Celery, wired up for you.
- A free plan and a 30-day trial, so you can evaluate without a card.
- Services in one project reach each other privately, so the database needs no public endpoint.
- Usage-based billing on top of the base fee makes the monthly cost hard to predict, and Django's memory footprint means you consume credits faster than a lighter stack would.
- Hobby is a one-developer workspace, so the moment a colleague joins, the floor under the bill goes from $5 to $20.
Render
- Best for
- Parking a Django demo for free, then moving to a simple paid tier when it matters.
- Pricing
- Free web services are available but spin down after 15 minutes without traffic. The cheapest paid instance, Starter, is $7/month for 0.5 vCPU and 512 MB RAM.
- A genuine free tier for web services, which is increasingly rare.
- Managed Postgres, cron jobs and background workers are all first-class, so Celery has somewhere to live.
- Release commands make running migrations on deploy straightforward.
- Free services spin down after 15 minutes idle, and a Django cold start is seconds — long enough that the first visitor notices.
- The $7 Starter tier is 512 MB, which is workable for a couple of gunicorn workers and tight for anything heavier.
Granite
- Best for
- Running Django together with the Postgres, the Celery broker and the media storage it needs, without wiring any of it up.
- Pricing
- Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
- Managed Postgres and Valkey sit in the same project as the app and talk over internal DNS — that covers the database and the Celery broker without a single connection string being exposed.
- S3-compatible storage with a built-in CDN is included, which is the right home for MEDIA_ROOT: uploads survive deploys and replicas without a shared volume.
- Databases have no public endpoint at all — they stay inside the cluster.
- Web app, Celery worker and Celery beat are three resources built from the same image with different commands, so they deploy together and share environment variables.
- No free tier — the cheapest way in is $9/month.
- The Hobby plan caps at 1 GiB per service, which is enough for a modest gunicorn set but not for a heavy one; Django pushes you to Advanced sooner than a lighter stack would.
- Fewer regions than the hyperscalers, and no multi-region routing yet.
PythonAnywhere
- Best for
- A first deployment, a teaching project, or a small internal tool where simplicity beats control.
- Pricing
- A limited free Beginner account runs one web app with restricted outbound internet. The Developer plan is $10/month: one web app on a custom domain, 5 GB of storage and 5,000 CPU-seconds a day.
- Built around Python specifically — no Docker, no build pipeline, no YAML to learn.
- A free tier that runs a real Django site on a subdomain, which is genuinely useful for coursework.
- MySQL and scheduled tasks are included rather than assembled.
- You work inside their environment rather than your own container, so anything unusual in your stack may simply not be possible.
- Background processing is limited compared with a general-purpose platform — Celery is awkward here.
- Not where you want to be if the project grows.
Koyeb
- Best for
- Edge presence with scale-to-zero, if the entry price is acceptable and traffic is bursty.
- Pricing
- Pro is $29/month plus compute and includes $10 of it; Scale is $299/month including $100. Serverless Postgres has a free tier of 5 hours a month at 0.25 vCPU, 1 GB RAM and 1 GB of storage, after which the smallest always-on instance is $29.76/month plus $0.50 per GB stored.
- Edge locations included rather than sold separately.
- Managed Postgres available without leaving the platform.
- Scale-to-zero is a much weaker fit for Django than for a compiled language: booting the interpreter and importing the app takes seconds, and that lands on a real user.
- The highest entry price of any managed option here.
Google Cloud Run
- Best for
- Stateless Django services with spiky traffic, where an idle app should cost nothing.
- Pricing
- No monthly fee. You pay per request and per resource-second, with a monthly free allowance. Cloud SQL and networking are billed separately.
- Scales to zero, so an idle service is genuinely free.
- Effectively unlimited scale ceiling.
- Takes any container image, so your slim multi-stage build applies unchanged.
- No persistent disk, so MEDIA_ROOT has to move to Cloud Storage before you deploy at all.
- Cold starts are seconds for Django, and min-instances to avoid them removes the scale-to-zero saving.
- Postgres, secrets and networking are separate GCP products you assemble and bill separately.
What does a Django app need from a host?
- Somewhere for MEDIA_ROOT
- User uploads written to local disk vanish on the next deploy and are invisible to a second replica. Either the platform gives you a persistent volume, or — better — you point Django at S3-compatible storage and stop thinking about it. Check this before anything else; it is the most common way a first Django deployment quietly loses data.
- Static files, separately
- collectstatic has to run during the build, and the result has to be served by something. WhiteNoise keeps it inside gunicorn and is fine for most sites; a CDN in front of object storage is better once traffic grows. Either way it is a build step the platform must let you run.
- Memory per worker
- Each gunicorn worker is a separate process with the interpreter and your whole application loaded. Memory scales with worker count, not with traffic, so the 256 MB and 512 MB tiers that suit a compiled binary are the wrong shape here. Size the plan by workers, then verify against real usage.
- Migrations as a release step
- manage.py migrate must run once per deploy, after the build and before the new version takes traffic — not in the container start command, where every replica would race to run it. Look for a release command or pre-deploy hook.
- A place for Celery
- If there is a queue, you need a long-running worker process and usually a beat scheduler, plus Redis or Valkey as a broker. A platform that only runs web services means renting something else for this.
- WSGI or ASGI
- gunicorn is the default and right answer for most projects. If you use Channels, websockets or async views, you need uvicorn workers instead — and a platform that does not terminate idle connections aggressively.
$ docker images django-app
REPOSITORY TAG SIZE
django-app naive 1.7GB
django-app slim 309MB
Where do background jobs and queue workers run?
In a process of their own, beside gunicorn rather than inside it. Celery is the default answer and needs a broker — Valkey or Redis — plus a worker started with celery -A proj worker; RQ is the lighter option when a single queue and Redis is all you want. On Granite the worker is a worker resource built from the same image with a different command, and the broker is a managed Valkey in the same project, reached over internal DNS — an Extra Small node is $8 a month against your credits. A deploy replaces the container, so a task that is running at that moment is only re-queued if you set acks_late; otherwise it is gone. Restarts after a crash work the same way, which makes idempotent tasks a requirement rather than a style preference.
How do scheduled tasks and cron work?
celery beat is a scheduler process, and exactly one of it may run. Two beat containers dispatch every periodic task twice, which is why beat is a separate resource with one replica and never a thread inside a web service you intend to scale. The alternative is a platform cron calling a management command: on Granite a cron-job resource runs python manage.py send_digests on a cron expression, always as a single container, with a Forbid or Allow setting for a run that overruns its next slot. Either way the output lands in that resource's own log — novps resources logs <id> -n 500 --search digest— and not in the web app's.
Is Postgres managed, and what about backups?
Managed everywhere here except Fly, where Postgres is an app you deploy and stay on call for. Granite takes scheduled backups into external storage and support will run point-in-time recovery for Postgres on request; the backup interval is not published, so confirm it before you promise anyone an RPO. The database has no public address at all — Django reaches it over internal DNS and you reach it through novps port-forward database <id> -l 5432 when you need psql. A pooler in front matters here because CONN_MAX_AGE makes every gunicorn worker hold its own connection open: eight workers across two replicas is sixteen sockets that never close on their own.
How do deploys and migrations work?
Either a push to the tracked branch, which builds an image and rolls it out, or a Docker tag the platform watches. collectstatic belongs in the build; manage.py migrate belongs in a release step that runs once. Render and Railway have one. Granite does not: run the migration from the resource's Console tab, or over a forwarded port from your machine, before the new image goes out. Never put it in the start command, where every replica races the others through the same schema. And whatever the rollback story is for the image, it is not a rollback for the data — an old container against a migrated database fails on the columns it cannot see.
What does it actually cost per month?
Web, Celery worker, Postgres and a broker, priced as of 1 September 2026. Render comes to $30: $7 for the Starter web service, $7 for the worker, $6 for a 256 MB Postgres and $10 for a 256 MB Key Value instance. PythonAnywhere is $10 flat with 5,000 CPU-seconds a day, but Celery is awkward there and the queue is really the point. Railway bills per second against a $5 minimum on Hobby. Granite is $9 with $15 of credits shared across all four pieces, of which the Valkey node takes $8 — and Hobby's 1 GiB per service is a couple of gunicorn workers, so a real Django set means Advanced at $39.
So which should you pick?
Your first ever deployment, or a teaching project. PythonAnywhere. It hides the parts you are not ready for, and the free tier serves a real site.
A demo that should cost nothing. Render's free tier, as long as you accept that the first visitor after an idle period waits several seconds for the app to wake up.
The fastest path to Django plus Postgres plus Redis. Railway. The templates assemble the whole stack, and you can be looking at a working site the same afternoon.
A production application with uploads and background jobs. This is where we would argue for Granite. Postgres and Valkey run in the same project as the app with no public endpoint, S3-compatible storage with a CDN gives MEDIA_ROOT a permanent home, and the web app, the Celery worker and beat are three resources from one image that deploy together. From $9/month with $15 of usage credits, though a real gunicorn set will want the Advanced plan.
Multiple regions, and you run your own database anyway. Fly.io.
Deploying a compiled service alongside it? The Go hosting comparison covers the same platforms with very different conclusions, and the app platform page covers workers and cron jobs in detail.
Hosting for other stacks
Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.
Vercel and six alternatives, weighed on the things that actually break when you self-host: ISR across replicas, image optimization and build-time env vars.
Six ways to run an Express, NestJS or Fastify service — weighed on the event loop, the connection pool, and what a long-lived process costs while it waits.
Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.
Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.
Seven platforms for Django, Flask, FastAPI or a script with no HTTP port at all — and how to tell which of those you are actually deploying.
Six platforms weighed on what an ASGI service actually needs: worker processes, connections that stay open, and a database pool that does not multiply out of control.
Seven options for the framework that ships no opinions — weighed on the WSGI server you have to bring, the session key you must keep stable, and the extensions that decide the rest.
Six platforms weighed on the things Symfony assumes: a warmed cache built at build time, Messenger workers that restart on deploy, and Doctrine migrations that run exactly once.
Seven platforms for a framework that renders on every request — weighed on streaming, adapters, and how far the loaders sit from the database.
Six platforms weighed on what the JVM actually asks for: memory it is allowed to use, a container that knows its own limits, and a start-up you can afford to repeat.
Six places to run a container image, compared on what actually bites: architecture mismatches, registry access, signal handling and the volume you assumed would still be there.
Five ways to serve HTML that is already written — and an honest note about which of them we are not the right answer for.