After 16 years, Heroku stopped building. Where do you actually go?
On February 6, 2026, Salesforce moved Heroku into sustain mode. No new features. Maintenance and security patches only. The platform that taught a generation of developers to git push heroku main is done evolving.
If you're still on Heroku, you need a plan. If you already left for Railway or Render, it's worth asking whether you solved the underlying problem, or just moved to a younger version of the same model.
What actually happened to Heroku
Salesforce acquired Heroku in 2010 for $212 million. For a while, investment continued. Then it slowed. Then it stopped.
The timeline:
- 2022: Free tier removed. Community trust damaged.
- 2023 to 2025: Feature development slowed to a crawl. No significant platform updates.
- February 2026: Sustain mode officially announced. The Heroku team is reassigned. Platform stays running but gets no new features.
Heroku isn't shutting down. Your apps will keep running. But you're now on a platform that will slowly fall behind on runtime versions, security patches, and ecosystem support. The question isn't whether to migrate, it's when and where.
The migration options, honestly evaluated
Option 1: Another shared PaaS (Railway, Render, Fly.io)
Railway is the most common destination. Good DX, active development, $100M in funding. Railway-level experience is genuinely excellent for small-to-medium projects.
Render offers straightforward deployment with a generous free tier. Predictable pricing. Good docs.
Fly.io focuses on edge deployment and global distribution. More complex than Railway or Render, but powerful for latency-sensitive applications.
The problem with this option: you're solving the same risk with the same architecture. Shared PaaS means your infrastructure lives on someone else's servers. If Railway changes direction, raises prices dramatically, or gets acquired, you're in the same position you're in now with Heroku.
This already happened once. It can happen again.
Option 2: BYOC (Bring Your Own Cloud)
BYOC platforms deploy to your cloud account. You get the push-to-deploy DX of a PaaS, but your containers, databases, and data live in your own AWS or GCP account.
If the BYOC vendor disappears tomorrow, your infrastructure stays. Your GKE clusters, your RDS databases, your Cloud SQL instances, they're just standard cloud resources in your account.
The platforms:
- AZIN: GCP BYOC via GKE Autopilot. No Kubernetes knowledge required. First cluster free. Full Heroku migration guide.
- Porter: AWS, GCP, Azure via managed Kubernetes. ~$225/month minimum on AWS.
- Flightcontrol: AWS-only via ECS. No Kubernetes. Free tier available.
- Northflank: Six cloud providers. BYOC on all plans including free tier.
For a detailed comparison: Best Heroku Alternatives in 2026
Option 3: Self-hosted (Coolify, Kamal, Dokku)
Install a PaaS on your own servers. Maximum control, maximum responsibility.
Coolify is the most popular (50K+ GitHub stars). Web dashboard, 280+ one-click services. You manage the servers.
Kamal is from 37signals (Basecamp/HEY). Docker deployment via SSH. No web UI. CLI-only.
Dokku is the original Heroku alternative. Proven, stable, single-server.
Great if you're comfortable managing Linux servers and want the lowest possible cost. Not great if you want managed databases, auto-scaling, or zero-downtime deploys out of the box.
Option 4: Go full cloud-native (ECS, GKE, EKS directly)
Skip the abstraction layer entirely. Deploy containers directly to AWS ECS, Google GKE, or manage your own Kubernetes. Full control. Full complexity.
This makes sense if you have a dedicated DevOps team. It doesn't make sense if your developers are also your ops team, which is most startups and small companies.
The actual migration process
Regardless of where you go, the migration follows the same pattern:
Inventory your Heroku resources. List every app, addon, and config var. Check for Heroku-specific dependencies (Heroku Postgres, Heroku Redis, Heroku Scheduler).
Containerize if you haven't. Most Heroku apps use buildpacks. If your app doesn't have a Dockerfile, create one. Most modern platforms support buildpack-style auto-detection, but a Dockerfile gives you the most portability.
Migrate databases first. This is the hardest part. Heroku Postgres to Cloud SQL, RDS, or self-managed Postgres. Use pg_dump/pg_restore for small databases. For larger databases with zero-downtime requirements, set up logical replication first, then cut over.
Deploy to the new platform in staging. Push your code to the new platform. Verify it works. Run your test suite against it. Check environment variables, build steps, and runtime behavior.
Switch DNS. Once staging is verified, point your domain at the new deployment. Monitor for 24 to 48 hours before tearing down the Heroku app.
Cancel Heroku. Remove addons first (they often have separate billing). Then delete apps. Then downgrade your account.
Which option should you pick?
If you want the fastest migration with the least change: Railway or Render. Same deployment model as Heroku. Lowest learning curve.
If you want to own your infrastructure and never be in this position again: BYOC (AZIN, Porter, Flightcontrol, Northflank). More setup upfront. Better long-term position.
If you want maximum control at minimum cost: Coolify or Kamal on a VPS. Requires server management skills.
If you have a DevOps team: Raw cloud services (ECS, GKE). Skip the abstraction.
The one option I'd avoid: staying on Heroku and waiting. Sustain mode means the platform will slowly degrade. Runtime versions will fall behind. Security patches will be slower. The longer you wait, the more technical debt accumulates.
The Heroku era was good. It's over. Pick your next platform based on where you want to be in three years, not just what's easiest today.
Top comments (1)
What about encore.cloud? It’s BYOC but you also get built in preview environments, observability (like free Datadog), and automated service catalog and API docs (like Backstage / Postman).