Where should Django store user uploads in production?

Not on the container's local disk. That filesystem is discarded on every deploy and is not shared between replicas, so uploads disappear or become randomly unavailable as soon as you scale past one instance. Two options work. A persistent volume attached to the service keeps files across deploys but ties you to a single instance. S3-compatible object storage, configured through django-storages, works with any number of replicas and puts a CDN in front of the files — this is the better default for anything that might grow.

How much RAM does a Django app need?

Size it by gunicorn workers rather than by traffic. Each worker is a separate OS process holding the interpreter and your imported application, so memory grows with the worker count and stays roughly flat as requests increase. In practice this means the smallest tiers on most platforms are the wrong shape for Django. Start with a conservative worker count, watch actual usage under real traffic, and add workers rather than provisioning generously up front.

Can I run Celery on the same platform as the web app?

On a general-purpose platform, yes, and you should. The worker runs the same image as the web service with a different command, so it always has the same code and settings, and it deploys in the same step. Beat, the scheduler, is a third resource on the same principle. You also need a broker — Redis or Valkey. Platforms that offer it as a managed service alongside the app save you from operating one; where that is not available, a queue backed by your existing database is a reasonable smaller-scale alternative.

Should Django run migrations on startup?

No. If migrate runs in the container's start command, every replica runs it simultaneously on every deploy, and two of them racing on the same schema is a genuinely bad afternoon. Run it as a release step: after the image is built, before the new version starts taking traffic, once. Every platform in this comparison has a mechanism for this, under names like release command or pre-deploy hook.

Is serverless a good fit for Django?

Less than for compiled languages. Scale-to-zero saves money only if cold starts are cheap, and starting Python, importing Django and loading your application takes seconds — a delay a real visitor sits through. It can still fit an internal tool that is idle most of the day and has no uploads on local disk. For a public site, a small always-on instance usually gives a better experience for similar money.

Do I need Docker to deploy Django?

No. Most platforms here detect a Python project, install from requirements.txt and run it, which is enough for a straightforward application. A Dockerfile earns its keep when you need system packages beyond Python, want the build reproducible, or care about image size. A multi-stage build that installs into a virtualenv and copies it onto a slim base image cuts the result by roughly five times, which shortens every pull and every scale-up.

Django Hosting: 7 Options Compared (2026) • Granite.so

Last updated 3 August 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.

At a glance

Sorted by entry price. Every provider here can build and run a Django service; the columns are what separates them.

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 3 August 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?

Pick the category before you pick the provider — it decides more than the logo does.

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.

Where should Django run?

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

Note how this differs from a compiled stack: for Django the serverless branch is the narrow case, not the cheap default.

The options

Prices as published by each provider on the date above. Check them before you commit — they move.

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: Hobby is $5/month including $5 of usage credits; Pro is $20/month per workspace including $20 of credits. A free plan gives $1 of monthly credits, and there is a 30-day trial.

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.
The Pro fee is charged per workspace, which adds up for small teams.

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: The Pro plan is $29/month; Scale is $299/month. Serverless Postgres has a small free allowance.

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 a Django app actually needs from a host

The requirements that matter for Django are different from the ones every generic hosting listicle repeats.

Django-specific criteria

These are the questions that decide whether a platform fits Django, as opposed to whether it runs Python at all.

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

The same Django project built two ways: once installed into a full python image, once multi-stage into a virtualenv copied onto a slim base. Five and a half times smaller for a few lines of Dockerfile, and worth doing on any platform that pulls the image on every deploy. Note where it stops, though: 309 MB is close to the floor, because the interpreter and site-packages ship with the application no matter what you do. Budget for that when you compare per-gigabyte pricing and cold pull times.

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.

See Granite pricing

Hosting for other stacks

Go hosting

Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.

Next.js hosting

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.

Rails hosting

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 hosting

Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.

Django hosting — 7 options compared