Django Hosting in 2026: $140+/Month on Heroku vs $38+ on Render vs $15–35 on Fly.io — Migrate the Bill or Exit Metered Compute?

A typical production Django app — one web process, one Celery worker, a scheduler, Postgres, and Redis — costs $140 a month or more on Heroku. The same stack runs for roughly $38 on Render, $15–35 on Fly.io, or a fixed $5–40 on a server you own. Those numbers come from Appliku's 2026 Heroku-alternative comparison, and they frame the question every Heroku team is asking in 2026: do you migrate to a cheaper metered bill, or exit metered compute entirely?

The headline numbers: one stack, four bills​

To keep the comparison honest, price the same stack everywhere: a Django web process, a Celery worker, a scheduler/beat process, a production-grade Postgres, and Redis for cache and the Celery broker. Here is what that costs per month in 2026:

The delta is the story. Moving the identical Django stack from Heroku to Render saves roughly $1,200 a year; moving it to Fly.io or owned hardware saves roughly $1,200–1,600 a year. And that Heroku column assumes only one dyno tier above hobby — add a second worker, a bigger database, or monitoring add-ons and the meter keeps running, because every Heroku component bills independently.

There is also a reason this comparison is urgent in 2026 rather than merely interesting. On February 6, 2026, Salesforce moved Heroku into a sustaining engineering model: no new features, no new Enterprise contracts, maintenance and security patches only. Staying put is no longer the neutral option — it means paying the highest bill on the table for a platform that has stopped evolving. (We covered what sustaining mode means for migration planning in a previous post.)

What's inside each number​

A price table is only as honest as its methodology, so here is the receipt behind every column.

Heroku (~$140). Two Standard-1X web dynos at $25 each for horizontal redundancy, one Standard-1X worker at $25, Heroku Postgres Standard-0 at $50 — the tier where production features like continuous backup and fast failover actually start — and Heroku Redis Mini at $15. That matches the $130–160 range independent migration guides quote for a small production Heroku stack. Note what the floor is not: a solo developer can run one Standard-1X dyno plus Postgres Essential ($5) for about $30 a month, but Essential Postgres has no row-limit-free production guarantees to speak of, and a single dyno sleeps through deploys. The $140 figure is the honest production floor, not the hobby floor.

Render (~$38+). Render is the closest Heroku-like experience: git-push deploys, managed Postgres, managed Redis-compatible Key Value, cron jobs. The math is straightforward — a $7 Starter web service, a $7 Starter background worker, Postgres from roughly $6–20 depending on tier and storage ($0.30/GB-month), and Key Value Starter at $10 for 256 MB. The "+" matters: Render bills per service, so every worker, cron job, and preview environment adds its own line item, and the free Postgres tier expires after 30 days. A team that grows from one worker to three watches the bill scale linearly, dyno-style.

Fly.io (~$15–35). Fly bills per VM-second, and small shared-CPU machines are cheap: a shared-cpu-1x with 256 MB runs about $2 a month, volumes cost $0.15/GB-month, and the first chunk of egress is generous. The $15–35 range assumes you run Postgres yourself on a Fly VM with a persistent volume — the classic fly launch --db path — which is exactly what the Appliku comparison prices. The caveat is Fly's managed Postgres: the Basic plan (shared 2× CPU, 1 GB RAM) starts at $38 a month before storage, which single-handedly blows past the top of the range. Fly's number is real, but it prices in database self-management.

Owned hardware (~$5–40 fixed). A Hetzner CX22 cloud server — 2 vCPUs, 4 GB RAM, 40 GB NVMe, 20 TB of included egress — costs around €3.50–4.50 a month, comfortably enough for a small production Django stack with Postgres and Redis in containers. A dedicated AX41 (Ryzen 5, 64 GB RAM, 2× 512 GB NVMe) runs about €37 a month and absorbs a far larger fleet. The defining property is not the low price — it is that the price is a ceiling. Add a second worker, a staging copy, or a side project on the same machine and the bill does not move.

What moves each number​

No single number survives contact with a real workload, so here is the sensitivity analysis — what pushes each column up or down.

Heroku moves on headcount of dynos and database tier. The jump from Postgres Standard-0 ($50) to Standard-2 ($200) alone exceeds Fly's entire range. Autoscaling adds dynos at $25–50 each without asking, and the add-on ecosystem (logging, monitoring, error tracking) typically contributes another $15–30 that teams forget to budget. Direction of travel: up, in $25+ increments.

Render moves on service count. One web service plus one worker plus database plus Redis is the $38 floor; each additional worker, cron job, or always-on preview environment adds $7–25. Storage grows at $0.30/GB-month with no shrink path. Direction of travel: up, in per-service steps — gentler than Heroku, but the same shape.

Fly.io moves on egress and machine count. Compute is the cheap part; bandwidth is the variable. Egress runs $0.02/GB in North America and Europe, $0.04/GB across Asia-Pacific, Oceania, and South America, and $0.12/GB in Africa and India. A media-heavy Django app serving a global audience can spend more on egress than on every VM combined — worth modeling before migrating, since Heroku and Render include far more generous bandwidth in their base prices.

Owned hardware barely moves at all. The CX22-to-AX41 ladder covers roughly €4 to €37 a month, and within a machine the marginal cost of another container is zero. What moves instead is your time: OS patching, Postgres backups, Redis persistence, TLS renewal. That is the genuine trade, and any honest comparison has to price it — which is exactly why the managed-on-your-server middle ground (Appliku's ~$20–40 all-in figure) exists: fixed hardware economics with the ops work rented out.

Move the bill or exit the meter​

With the numbers grounded, the decision sorts into two genuinely different moves.

Migrating PaaS-to-PaaS swaps a bigger metered bill for a smaller one. Render gives a Heroku team the shortest migration path — buildpacks, managed Postgres, render.yaml blueprints that map almost one-to-one from app.json — at roughly a quarter of the cost. Fly.io goes further on price but asks more in return: Dockerfiles instead of buildpacks, self-managed Postgres unless you pay $38+ for managed, and a machines-and-volumes mental model instead of dynos-and-add-ons. Both are still meters. Both can still surprise you — Render through service sprawl, Fly through egress.

Migrating to owned hardware exits metering entirely. The bill becomes a flat server rental plus whatever management layer you choose: DIY with Dokku or Coolify, or a managed control plane on your own Hetzner or bare-metal box. The economics invert — over-provisioning is free, idle staging environments cost nothing, and growth within the machine is pure margin. The cost is operational responsibility, and teams should be clear-eyed that Postgres backups and security patching are now their runbook, not a vendor's status page.

When is each right? If the team has no ops capacity and the app fits one web service plus one worker, Render's $38 is the rational local optimum. If the team can run containers and wants edge regions, Fly's $15–35 is remarkable value with eyes open on egress and database management. If the team already runs infrastructure — or wants the flat economics to compound across many apps — owned hardware wins by an amount that grows every year: the $1,200–1,600 annual Heroku delta buys a lot of server.

The Django migration checklist​

Whichever path you pick, the same five Django-specific items determine whether the migration is a weekend or a quarter.

1. Buildpacks vs Dockerfile. Heroku's Python buildpack (detect Python version, install requirements, collect static, run release-phase migrations) has no equivalent outside Heroku. Render supports both native Python and Docker; Fly.io and owned hardware want a Dockerfile. Write the Dockerfile first, while Heroku is still running — it is the artifact every destination accepts, and gunicorn + collectstatic + migrate in the release phase ports verbatim.

2. Managed-Postgres exit. pg_dump from Heroku Postgres and pg_restore into the new database is the easy part. The checklist is the extensions (pg_trgm, postgis, pgvector — verify each exists at the target), the connection math (Heroku's connection pooling via PgBouncer vs direct connections to a self-managed Postgres), and the cutover (put the app in maintenance mode or accept a brief write freeze; logical replication is overkill for most Django apps).

3. Celery workers and beat. On Heroku these are dyno process types (worker: celery -A proj worker, plus Scheduler or beat). Every destination needs them as first-class citizens: Render background workers plus cron jobs, Fly machines with a [processes] group, systemd units or containers on owned hardware. Do not forget beat — periodic tasks silently not running is the classic post-migration discovery.

4. Static and media assets. Heroku-era Django typically pairs WhiteNoise for static files with S3-compatible storage for user uploads. WhiteNoise ports everywhere unchanged, which makes static the easy half. Media needs a real object store decision at migration time — the new platform's volumes work for small scale, but object storage (with django-storages) is the durable answer, and migrating the existing bucket contents is the long pole.

5. Config, secrets, and domains. DATABASE_URL, REDIS_URL, SECRET_KEY, and third-party API keys move from Heroku config vars to the new platform's env management; rotate the database credentials at cutover rather than reusing them. Custom domains mean new DNS plus TLS provisioning — automatic on Render and Fly, cert-manager or Caddy on owned hardware — and a TTL-lowering pass before migration day so the cutover propagates in minutes, not hours.

Run that checklist against a staging copy first, cut over with a maintenance window measured in minutes, and keep the Heroku app (scaled down, not deleted) for one billing cycle as a rollback target. The rollback insurance costs one month of the old bill; the alternative costs a weekend.

Appliku's table will drift as prices change, but its shape has held for years: Heroku most expensive with the deepest lock-in, Render the closest Heroku-like at a fraction, Fly.io cheapest if you run your own database, owned hardware cheapest overall with a flat ceiling. In 2026, with Heroku in sustaining mode, the table is no longer a curiosity — it is a migration plan with the math attached. The only wrong answer is letting the next $140+ invoice land without having chosen which column you want to be in.

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.