Migrating Off Heroku Without Tears: A 2026 Cost Playbook
Heroku's free tier is gone and paid plans are expensive. Here's how to pick the right destination — Render, Fly.io, or AWS — and migrate without breaking it.
By Andrii Votiakov on
Heroku used to be the path of least resistance for small apps and side projects. Then Salesforce killed the free tier, raised prices on everything else, and a lot of engineering teams are paying $500-2,000/month for workloads that should cost $50-200. I've helped a dozen teams move off Heroku in the last two years. Here's the honest playbook.
Quick answer
Your best destination depends on how much you care about simplicity vs control. Render or Railway for teams that just want Heroku-like simplicity at lower prices. Fly.io if you need edge deployment or fine-grained control. AWS ECS or GCP Cloud Run if you're already in those clouds or need the full ecosystem. In every case, migration takes 1-5 days, not weeks.
Why Heroku costs so much now
Heroku's pricing model worked when dynos were cheap and the free tier absorbed small apps. Post-2022 pricing is a different story.
A Standard-2X dyno (1 GB RAM, 2x CPU share) costs $50/month. Scale to 3 dynos for basic HA and you're at $150/month before add-ons. Heroku Postgres at Standard-0 (4 GB storage, 25 connections) is $50/month. Add Redis at $30/month, Papertrail or Datadog at $20-100/month, and a modest three-service app lands at $300-400/month.
The same setup on Render, Railway, or a small VPS costs $40-100/month. The gap is real.
Mapping your app to a destination
Not every app suits every destination. Here's how I think about it.
| App shape | Best fit | Why |
|---|---|---|
| Simple Rails / Django / Express | Render or Railway | Near-identical DX to Heroku |
| Multi-region or edge latency matters | Fly.io | Anycast network, regional VMs |
| Already on AWS, needs ECR + RDS | ECS Fargate | Native integrations, same account |
| Already on GCP or purely HTTP | Cloud Run | Per-request billing, scales to zero |
| Need full Kubernetes later | EKS or GKE | Plan the migration in stages |
Render and Railway: the easy exit
Both Render and Railway are built for the exact use case Heroku owned. Buildpack-compatible deploys, automatic HTTPS, managed Postgres, Redis, and preview environments.
Render runs services from $7/month (starter, 512 MB RAM) to $85/month (pro, 4 GB RAM). Managed Postgres starts at $7/month. Egress is free up to 100 GB. For a typical three-service app, you're looking at $30-80/month vs Heroku's $300+.
Railway bills per-usage: $0.000463/vCPU-second, $0.0000025/MB-second. For spiky or low-traffic apps this can be extremely cheap — I've seen teams pay $8-15/month for apps costing $120/month on Heroku.
Migration path is straightforward. Port your Procfile, add a render.yaml or railway.toml, point your DNS, and switch the database connection string. Done in an afternoon for most apps.
Fly.io: for when topology matters
Fly.io is the most Heroku-like in spirit but the most different in execution. You ship a Dockerfile (or use buildpacks), and Fly deploys your app to micro-VMs across its global network of ~35 regions.
Pricing: shared-CPU-1x (256 MB) is $1.94/month. A 1 GB RAM shared-CPU instance is $5.70/month. Add a managed Postgres cluster and you're at $15-30/month for a basic app.
Where Fly wins: apps that need low latency for global users, WebSocket workloads, or apps that should run close to users in specific regions (EU, APAC). I've also seen teams use Fly for preview environments because the per-VM pricing makes spinning up ephemeral instances cheap.
The DX is different from Heroku — more Docker-centric, more config to learn — but the flyctl CLI is genuinely good and the documentation is honest about trade-offs.
AWS ECS Fargate: when you're already in AWS
If your databases are on RDS, your secrets are in Secrets Manager, and your team already uses the AWS console, Fargate is the natural destination. You keep everything in one account, use IAM roles instead of environment variable hacks, and get VPC-native networking.
Cost for a 0.5 vCPU / 1 GB Fargate task: ~$30/month on-demand, ~$15/month with Compute Savings Plans. Run two tasks for HA and you're at $30-60/month for the compute layer.
The migration work is mostly writing task definitions and a service definition, plus an Application Load Balancer ($16-20/month). Not trivial, but not a month-long project either. I typically get a Heroku app running on Fargate in 1-2 days. See the /blog/aws-fargate-cost-optimisation post for the cost levers once you're there.
What you give up: Heroku's zero-config build pipeline. You'll need an ECR repository, a Docker build in CI, and a deployment step. Worth it if you're already in AWS.
GCP Cloud Run: scales to zero
Cloud Run is the best fit for HTTP services with variable traffic patterns. You pay only when your container is handling requests. Idle time costs nothing.
Pricing: $0.00002400/vCPU-second, $0.00000250/GB-second of memory. The first 2 million requests/month are free. For a service handling 500k requests/month at 200ms average latency, your bill is roughly $5-15/month.
The trade-off is cold starts. Cloud Run containers cold-start on demand, and minimum instances cost money ($0.00001800/vCPU-second even when idle). For latency-sensitive apps, set min-instances: 1 on Cloud Run which costs around $12/month per vCPU — still far cheaper than Heroku.
Cloud Run is also where I'd put apps that are just HTTP APIs with no persistent state. Simple, cheap, managed.
The migration checklist
Regardless of destination, these steps apply.
- Audit Heroku add-ons first. Some add-ons (Heroku Connect, Heroku Scheduler) have no direct equivalent. Find replacements before you start.
- Export your Heroku Postgres database with
heroku pg:backups:download. Restore it in the new platform before switching DNS. - Move secrets to proper secret management. Heroku config vars → AWS Secrets Manager, GCP Secret Manager, or Doppler. Not
.envfiles committed to git. - Set up health check endpoints. Most platforms need a
/healthor/healthzendpoint returning 200. Add one if you don't have it. - Test the build in CI before cutting over. Catch runtime dependency differences before your DNS switch.
- Blue/green cutover with DNS TTL. Lower TTL to 60 seconds 24 hours before migration, then cut over and roll back quickly if needed.
Realistic numbers
Here's what I've seen on actual migrations:
| Heroku bill | Destination | New bill | Savings |
|---|---|---|---|
| $320/month (3 dynos + Postgres + Redis) | Render | $65/month | 80% |
| $480/month (5 dynos + Standard Postgres) | Fargate + RDS | $110/month | 77% |
| $190/month (2 dynos + Redis) | Railway | $22/month | 88% |
| $800/month (8 dynos, background workers) | ECS Fargate + Spot | $180/month | 78% |
| $1,200/month (high-traffic API, 10 dynos) | Cloud Run | $95/month | 92% |
Migration time in each case: 1-4 days of engineering time.
If your team is still on Heroku and the bill is stinging, the move is usually faster than you think. I help with destination selection, migration planning, and the actual cutover. You only pay if I save you money. Book a call and we'll figure out the right path in 30 minutes.