Django Heroku Exit 2026: Appliku vs Railway vs Render Priced for a Real Stack

On February 6, 2026, Heroku's chief product officer confirmed what the ecosystem had whispered for years: Salesforce is moving Heroku into sustaining engineering mode — maintenance and security patches, no new features, no new Enterprise contracts. The platform that taught a generation to git push heroku main is done evolving. (We covered what that means for the migration decision itself earlier this month.)

This post answers the next question, for one specific audience: if you run Django, where do you actually go? Most 2026 roundups compare platforms on generic dyno parity — one container here, one container there. But a Django deploy is never one container. It is a shape: a web process, a Postgres database, a Celery worker, a Redis broker, static assets, and a scheduler. Price the shape, not the container, and the shortlist reorders itself.

That is what Appliku's 2026 Heroku-for-Django guide got right, and this post recomputes its shortlist — Appliku vs Railway vs Render — against that concrete stack, adds the flat-Hetzner-box baseline no PaaS comparison wants to show you, and closes with the Django-specific migration checklist no generic comparison ever includes.

The reference stack we're pricing​

To keep every platform honest, fix one stack for the whole post — a small production Django SaaS, always on, no sleeping:

• 1 web service running Gunicorn (512 MB–1 GB RAM)
• 1 Celery worker (512 MB RAM)
• Postgres (a few GB to start, automated backups expected in production)
• Redis (Celery broker plus cache)
• Static assets (Whitenoise or object storage — effectively free at this scale)
• Scheduler (Celery beat or a cron equivalent)

Here is that stack priced four ways, from published list prices and Appliku's 2026 comparison, with the flat-box baseline:

Two things jump out. First, the metered PaaS options cluster: Railway, Render, and Appliku all land the reference stack somewhere in the $16–40 band, roughly a fifth of Heroku's production shape. Second, the flat box is not in the same sport: the whole stack fits on a €5.49 VPS because a small Django SaaS genuinely fits in 2 vCPU and 4 GB of RAM. Everything above that line is paying for management, not hardware.

Where each number comes from​

Heroku: $22 at the floor, $100+ when it's real. The $22 hobby floor is Basic dynos ($7 each, always on, 512 MB) plus Essential-0 Postgres ($5, 1 GB storage, no row limit) plus Key-Value Mini ($3). It is honest pricing for a side project. Production is where the shape bites: Standard-1X dynos at $25 each, Standard-0 Postgres at $50 (the first tier with production-grade backup and failover behavior), and a Redis plan above Mini. Two web/worker dynos plus Standard-0 alone is $100 before the scheduler's one-off dyno hours or a single add-on. Appliku's $140+/mo figure for web plus worker plus scheduler plus Postgres plus Redis is the realistic production total, not a scare number.

Railway: ~$20–30, metered by the resource-hour. Railway's plans are simple — $5 Hobby or $20 Pro, each including an equal amount of usage credit — and everything else meters: roughly $10/GB-mo of RAM, $20/vCPU-mo of CPU, $0.15/GB-mo of volume storage, $0.05/GB of egress. The Django-relevant twist is that Postgres is not a separate SKU; it is an ordinary service drawing from the same usage pool as your web and worker. The reference stack typically consumes $20–30 of metered resources: ~1.5 GB of RAM across web, worker, and Postgres plus fractional vCPU. The meter cuts both ways — idle side projects can dip toward the $5 base, but there is no ceiling, only a dashboard.

Render: $21 at the floor, ~$38+ production-shaped. Render prices per service, Heroku-style: Starter web at $7 (512 MB, 0.5 CPU), Starter background worker at $7 (note: workers have no free tier even though web services do), Starter Postgres at $7 (1 GB storage, 256 MB RAM). That is the $21 floor, and a community blueprint puts the smallest viable web-plus-worker-plus-Postgres shape at $21–26. Step the web service up to Standard ($25, 2 GB RAM) for anything with real traffic and the stack lands around $38+. Two Django-specific Render facts matter here: Render Postgres has no built-in connection pooling, so multi-worker Gunicorn plus Celery means budgeting for PgBouncer (or keeping CONN_MAX_AGE at zero and eating the per-request connect cost), and Render's free web tier sleeps after 15 minutes of idle, so it is not part of any serious comparison.

Appliku + Hetzner: ~$16–40, capped by the server. The bottom of this range is arithmetic, not marketing: a Hetzner CX23 at €5.49/mo plus Appliku Hobby at ~$10/mo is about $16 all-in, running the web service, Celery worker, Postgres, and Redis as containers on one box with git-push deploys, nginx, and auto-SSL managed for you. The top of the range is a bigger server, not more services — Appliku charges per server, not per app, so the second Django project on the same box costs $0 extra. That per-server pricing is the whole economic argument: your costs grow when you outgrow iron, not when you add a process type.

The sensitivity check: what happens when you're worker-heavy​

The reference stack has one worker. Real SaaS Django apps often have two or three, plus beat. This is where per-service pricing diverges from flat pricing, so run the same stack with three workers:

This table is the post in miniature. Every managed PaaS taxes the worker count — Heroku Standard charges $25 per additional worker, which is why worker-heavy Django shops were always Heroku's most overbilled customers. The flat box does not care how many processes you run until you exhaust 4 GB of RAM, and three Celery workers plus Gunicorn plus Postgres plus Redis still fit comfortably. If your Django app is worker-heavy today or will be within a year, price the three-worker column, not the one-worker column.

Which shortlist entry wins for which Django profile​

The solo-dev side project: Railway. The $5 Hobby base with $5 of included usage means a small always-on Django app with Postgres often lands under $10 total, deploys from GitHub in minutes, and needs no server thinking whatsoever. Render's Starter floor is comparably cheap, but Railway's usage pool (Postgres included, no per-service minimums beyond the base) fits the bursty, mostly-idle side-project shape better. Caveat: watch the meter once the project gets traffic — the same usage pool that makes idle cheap makes viral expensive.

The worker-heavy SaaS: Appliku + Hetzner. Nothing in the shortlist beats a flat box for process count. Web, three workers, beat, Postgres, Redis, and a second staging copy of all of it can share one €5.49–€12 server under a ~$10 Appliku plan. The tradeoff is real but bounded: you own the server in the sense that it is yours (fixed IP, your data, no platform lock-in), while Appliku manages the OS, Docker, TLS, and deploys. For a SaaS whose Heroku bill is mostly $25 dynos multiplied by process count, this is typically a 5–8x cost reduction with the git-push workflow intact.

The team that wants Heroku's git-push muscle memory intact: Render. Render is the closest thing to Heroku's workflow in 2026: native Python runtime (no Dockerfile required to start), Blueprint YAML that plays the role of app.json, one-off jobs and cron that map cleanly from Scheduler, a dashboard organized around services rather than servers, and per-service pricing the finance team can read without a metering dictionary. It costs more than Railway at idle and more than Appliku at scale, but migration risk is lowest — the team keeps thinking in services, not servers, and the Postgres story (managed backups, forking, read replicas upmarket) is the most Heroku-complete in the shortlist.

The Django migration checklist​

Whichever entry you pick, the migration has Django-specific steps no generic PaaS guide covers. In dependency order:

1. Buildpack to image. Heroku's Python buildpack did three invisible jobs: pinning the Python version, installing requirements, and hooking collectstatic into the build. Reproduce all three explicitly — a Dockerfile (or Nixpacks config on Railway) with a pinned python:3.x-slim base, a layer-cached pip install, and a build-phase collectstatic --noinput. Audit for buildpack-only behavior first: bin/post_compile hooks, GDAL/WeasyPrint system packages, DATABASE_URL parsing via dj-database-url.
2. Collectstatic in CI, verified. Static handling breaks silently — the deploy succeeds and the CSS 404s. Decide Whitenoise (simplest; serves from the web dyno with CompressedManifestStaticFilesStorage) versus object storage (required once you have multiple web replicas or a CDN), run collectstatic in the build step, and add a deploy smoke test that fetches one hashed static URL with a 200.
3. Celery worker and beat topology. Map each Procfile entry (web, worker, beat) to the new platform's process model: Railway services, Render web plus background workers plus cron jobs, Appliku containers on the box. Beat is the one teams forget — it needs exactly one replica, and on platforms without Heroku's dyno formation that means saying so explicitly. Carry over CELERY_BROKER_URL (Redis) and confirm visibility timeouts still match your longest task.
4. Postgres migration. pg_dump from Heroku, restore into the new database, then cut over with a maintenance window or a follow-and-promote if the platform supports it. Check extension availability (pg_trgm, postgis, pgvector) before migration day, not during it — managed Postgres tiers differ in which extensions they allow. Reset sequences are automatic with a full dump/restore; they are the classic gotcha with table-by-table copies.
5. Config vars to env groups. Export heroku config, then re-key deliberately: SECRET_KEY rotated (it lived in Heroku's store; treat the move as a rotation event), ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS updated to the new domains, DATABASE_URL/REDIS_URL repointed, email and S3 credentials confirmed region-correct. Delete every HEROKU_* var rather than carrying them over as dead weight.
6. Connection pooling. Heroku Postgres sat behind PgBouncer-friendly defaults and Django's CONN_MAX_AGE behaved. On Render there is no built-in pooler — either add PgBouncer or keep persistent connections at zero. On Railway and Appliku, Postgres runs close enough that per-request connects are cheap, but set CONN_MAX_AGE deliberately and load-test the worker count you actually run, not the reference stack.
7. Media and uploads off ephemeral disk. Heroku's ephemeral filesystem already forced this lesson — user uploads live on S3-compatible storage, not local disk. Confirm DEFAULT_FILE_STORAGE/STORAGES points at the bucket, migrate any files that accumulated on dyno-local disk during development, and verify signed-URL expiry still suits your access patterns.
8. Scheduler and release phase. Heroku Scheduler becomes cron jobs (Render, Appliku) or a scheduled service (Railway); Heroku's release phase (release: python manage.py migrate) becomes a deploy hook or pre-deploy command on every platform in the shortlist. Run migrations automatically on every deploy the way the release phase did — the teams that regress to manual migrate are the teams that ship a migration-less deploy within a month.

Work through that list and the migration is a long weekend, not a quarter. Skip steps 2, 3, or 6 and it becomes a long month of brownouts — those three are where Django migrations actually fail.

The shortlist, in one paragraph​

Heroku's sustaining-mode announcement turned every Django team's "someday we'll leave" into a roadmap item with a date. For the solo side project, Railway's usage pool is the cheapest always-on git-push workflow. For the worker-heavy SaaS, Appliku on a flat Hetzner box collapses the per-process tax to near zero. For the team that wants Heroku's muscle memory with the lowest migration risk, Render's service model is the closest surviving relative. All three beat Heroku's production shape by 3–8x on the same stack — the only wrong move is repricing the invoice instead of replacing the platform.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If the flat-box math in this post resonates, that is the model taken to its conclusion: Render-compatible deploys with no per-service meter at all. Star the repo on GitHub or deploy your first app today.