Picking a Heroku alternative and moving to it without downtime
The right Heroku alternative depends on why you’re leaving. If it’s cost at moderate scale, a managed platform like Render or Fly.io is usually the smallest step. If it’s limits – networking, compliance, database size or control – AWS or Google Cloud with containers is the better destination. I help you pick, then migrate from Heroku with a rehearsed cutover and no surprises.
I’ve run production systems on AWS and Google Cloud, from Rails platforms like MyPerks to Indiemaker on Django and Postgres on GCP.
When leaving Heroku makes sense (and when it doesn’t)
Heroku still works well for a small team that values never thinking about infrastructure, but since February 2026 it has been in a sustaining engineering mode – maintained and supported, with no new features planned. Don’t migrate because a blog post said so. Migrate when one of these is true:
- The bill has outgrown the value. Large dynos and Postgres plans get expensive compared with equivalent compute elsewhere. Price it properly – check each provider’s current pricing page, and include the engineering time you’ll spend running the replacement.
- You’ve hit a platform limit: private networking needs, data residency, request timeouts for long-running endpoints, or database features and extensions you can’t enable.
- Compliance or enterprise customers require controls you can’t demonstrate on a shared platform.
If none of those apply, stay. A migration has a real cost, and the time is often better spent on the product.
Heroku alternatives compared
- Render and Railway – closest to the Heroku experience: Git push deploys, managed Postgres and Redis, preview environments. Smallest migration effort.
- Fly.io – runs your containers close to users in many regions. Good for latency-sensitive apps; expect to learn more of its model than you would with Render.
- AWS (ECS on Fargate, including ECS Express Mode) or Google Cloud Run – more setup, more control, and usually the cheapest at scale once it’s built. Managed databases via RDS or Cloud SQL. This is where a Heroku to AWS migration ends up.
- Your own VMs with Kamal – simple container deploys to servers you control. Cheap and transparent, but you own patching, backups and on-call.
Whatever you choose, describe the infrastructure in code (Terraform or the platform’s config file) so the next move isn’t another archaeology project.
How I migrate from Heroku
- Inventory everything Heroku does for you. Procfile process types, buildpacks, config vars, add-ons (Redis, Scheduler, logging, email), custom domains and certificates, release phase commands, review apps. Each one needs a named replacement.
- Containerize. A Dockerfile, or Cloud Native Buildpacks if you want to stay close to Heroku’s build. The app reads all config from environment variables, as it should already.
- Move compute first, data second. Run the new stack against the existing Heroku Postgres and Redis over TLS. Heroku can change those credentials at any time, so fetch the connection URLs from the Heroku app’s config rather than copying them, and note that Private and Shield tier databases restrict outside access. Heroku runs on AWS, so placing the new compute in the matching region keeps latency low during the transition.
- Shift traffic gradually. Lower DNS TTLs days ahead, then send a slice of traffic to the new stack, compare error rates and latency, and increase. Rollback is a DNS or load balancer change.
- Migrate the database last. Covered below.
- Decommission. Scale Heroku to zero and keep it, add-ons included, for a week as a fallback. Then take a final backup, remove the add-ons and delete the app.
Moving the Postgres database
This is the step that needs the most care. Heroku Postgres doesn’t give you superuser access, and options for replicating out to another provider are limited, so check what your current plan supports before planning around logical replication.
For most databases the dependable path is a short, rehearsed maintenance window: put the app in read-only or maintenance mode, pg_dump in custom format, pg_restore with parallel jobs into the new database, verify row counts and sequences, switch the connection string. Rehearse it on a copy twice so you know the exact duration. For very large databases, ask Heroku support about assisted migration options before you design anything clever.
If you’re also changing database engines or need true zero downtime, see database migrations and my notes on zero-downtime deployment.
Questions
What is the best Heroku alternative?
For the closest experience with the least migration work, Render or Railway. For global latency, Fly.io. For control and cost at scale, AWS or Google Cloud with containers and a managed database. The best choice depends on why you’re leaving: cost, limits or compliance.
How long does it take to migrate from Heroku?
A single app with Postgres and Redis can move in a couple of weeks including rehearsals. Apps with many add-ons, several services or a large database take longer. Most of the time goes into the inventory and the database rehearsal, not the deploy itself.
Can we migrate from Heroku with zero downtime?
The application tier, yes – run both stacks and shift traffic gradually. The database is harder because of the replication options available on Heroku Postgres. Most teams accept a short, rehearsed maintenance window for the database switch, scheduled at their quietest hour.
Is a Heroku to AWS migration worth it?
It’s worth it when you have the scale to benefit from cheaper compute or need features Heroku doesn’t offer, and someone on the team to own the infrastructure. For a small team without that, a managed platform alternative often saves more than it costs.
Thinking about leaving Heroku?
Tell me what’s pushing you off it. In a two-week sprint I’ll recommend a destination, containerize the app and aim to have it running on the new platform alongside Heroku.
GMT+2 · Full EU overlap · US East mornings