Heroku Just Told You It's Time to Leave (Read Between the Lines)

When Salesforce killed Heroku's free tier in 2022, it wasn't subtle about the message: Heroku is for enterprises now, and if you can't pay enterprise prices, you should leave.

The company that once defined what developer experience should look like—git push to deploy, instant scaling, no ops required—has spent the years since making clear it no longer cares about the developers who made it famous.

For founders still on Heroku, the question isn't whether to migrate. It's how soon.

The Slow Decline

Heroku's trajectory since the Salesforce acquisition has been a masterclass in how to extract value from a platform while investing nothing in its future.

The free tier elimination was the most visible cut, but it followed years of stagnation. Features that competitors shipped years ago—native Docker support, ARM instances, improved build systems—never arrived. Pricing stayed flat while AWS, GCP, and newer platforms dropped costs. The platform that pioneered the "buildpack" concept watched as competitors shipped better versions of the same idea.

More concerning for anyone still running production workloads: Heroku's status page tells a story of increasing reliability issues. Outages that would have been unthinkable in the platform's prime have become regular occurrences. The team that made Heroku great has largely left, and it shows.

What Made Heroku Great

Understanding why Heroku mattered helps clarify what you're looking for in an alternative.

Before Heroku, deploying a web application meant provisioning servers, configuring web servers, managing databases, setting up deployment pipelines, and handling scaling manually. Heroku compressed all of that to "git push heroku main." It was magic.

The platform bet that developers would pay a premium for not having to think about infrastructure. That bet was correct. Heroku's per-dyno pricing looked expensive compared to raw compute, but the engineering time it saved made it cheap on a total-cost basis.

The company also understood developer experience at a deep level. The CLI was excellent. The documentation was comprehensive. The add-on ecosystem solved common problems with one click. Everything worked together seamlessly.

This is the bar any alternative needs to clear: does it save enough engineering time to justify its cost premium? Does it actually work reliably? Is the developer experience coherent?

The Migration Options

The good news is that the market has responded to Heroku's decline with an explosion of alternatives. The bad news is that there are so many options that choosing is its own project.

Render is the most direct Heroku replacement. Similar mental model, similar pricing structure, similar "just push and it works" experience. They've explicitly positioned themselves as "Heroku, but actually maintained." For teams that loved Heroku's approach and just want it to work again, Render is the obvious choice.

Railway takes a similar approach but with a more modern twist—better native support for monorepos, more flexible infrastructure primitives, slicker UI. It's what Heroku might have become if it had kept innovating. Good for teams building more complex applications that still want managed simplicity.

Fly.io is more powerful but more complex. It gives you containers running on their edge network, with excellent global distribution and performance. But you're managing more of the infrastructure yourself. Good for teams that have outgrown the Heroku model but don't want to go full Kubernetes.

Vercel and Netlify work great if your application fits their model—primarily frontend, serverless functions for backend logic. They're not general-purpose Heroku replacements, but for the right architecture, they're better than Heroku ever was.

AWS/GCP/Azure managed services are always an option if you want to stay on hyperscale platforms. App Runner, Cloud Run, and Azure Container Apps all offer Heroku-like simplicity within the larger cloud ecosystems. Good if you're already committed to one of those clouds for other services.

The Migration Process

Moving off Heroku isn't technically difficult—the platform's simplicity cuts both ways. If you can git push to deploy, you can git push somewhere else.

The actual work is in the details:

Add-ons are the hard part. Heroku's add-on marketplace handles databases, caching, monitoring, logging, and dozens of other services. Each of those needs a replacement on your new platform. Some platforms have equivalent marketplaces. Others expect you to provision services separately.

Environment variables need migration. Export your Heroku config vars and import them to the new platform. But also audit them—you'll find old variables you forgot about, secrets that should be rotated, and configurations that don't apply to the new environment.

Database migration needs planning. If you're on Heroku Postgres, you need to move that data somewhere. Most alternatives offer managed Postgres, but the migration itself requires coordination. Plan for maintenance windows and test your backup/restore process.

CI/CD pipelines need updating. If you're using Heroku's built-in CI or pipeline features, you'll need to replace those with GitHub Actions, GitLab CI, or similar.

Custom domains and SSL need reconfiguration. DNS changes propagate slowly. Plan the cutover carefully to minimize downtime.

When to Move

The pragmatic answer: as soon as you have time to do it properly. Every month you stay on Heroku is another month accumulating technical debt on a declining platform.

But timing matters for a few reasons:

Don't migrate during a crisis. A calm, planned migration goes much smoother than a panicked one. If you're mid-fundraise, mid-launch, or mid-any-other-high-stakes-period, wait until things calm down.

Combine with other infrastructure work. If you're already planning to upgrade your database, refactor your deployment pipeline, or make other infrastructure changes, bundle the Heroku migration with that work.

Budget actual engineering time. Migration is real work. It's not a one-day project. Block out the calendar time and treat it as a legitimate priority, not something to squeeze in between feature work.

The Bigger Lesson

Heroku's decline is a reminder that platform risk is real. When you build on someone else's platform, you're subject to their priorities. Heroku's priorities stopped including developers like you.

This doesn't mean you should run your own infrastructure. The time cost of that approach is rarely worth it for startups. But it does mean you should choose platforms where your interests and the platform's interests remain aligned.

Render and Railway are venture-backed companies competing for developer adoption. Their incentive is to keep developers happy. That alignment might change someday, but right now it's real.

Heroku stopped competing years ago. It's time to move on.