No, Heroku is not dead: it is operational, supported, and still runs a large number of production applications. But the question people are really asking is whether Heroku's trajectory since the Salesforce acquisition, including the retirement of the free tier and its pricing and product direction, makes it a safe long-term home for a growing business. That is a vendor risk question, and it deserves a more careful answer than a headline.
If you are reading this, you probably did not choose the question. A board member forwarded a "Heroku exodus" article, or a pricing email landed, or your invoice crossed a threshold that made finance ask what exactly you are paying for. Now you own the answer: is the platform your business runs on a safe place to stay, and if not, when and how do you leave? The cost of getting this wrong is not the monthly invoice. It is an unplanned migration triggered by a vendor announcement, executed on someone else's timeline, at whatever moment is worst for your roadmap.
The cheaper path, in both engineer hours and business risk, is to decide deliberately. This post gives you the factual record, a framework for reading it as vendor risk, an honest account of when staying is the right call, and a concrete picture of what the exit looks like if you decide to move.
Heroku is alive. The platform deploys apps, the dashboard works, support responds, and Salesforce continues to operate it as a commercial product. Anyone telling you Heroku will shut down next quarter is speculating, and building a migration plan on speculation is how you burn a quarter of engineering time on the wrong project.
The honest version of the question is not "is Heroku dead" but "is Heroku still good as a long-term platform bet for a company like mine." That question has a real answer, and it starts with the record.
Stick to the documented facts. Salesforce acquired Heroku in 2010. For roughly a decade afterward, Heroku's model, including a permanent free tier, stayed broadly stable. Then in August 2022, Heroku announced the retirement of its free product plans: free dynos, the free Postgres tier, and free Redis were discontinued that November. Lower-cost paid plans were introduced in their place, and Heroku's published pricing today starts at $5 per month for its entry Eco dyno plan, with Standard dynos listed at $25 per month per dyno and Performance dynos ranging into the hundreds of dollars per dyno per month. Those numbers come from Heroku's own public pricing page; your invoice is the only figure that matters for your decision, and you already have it.
Alongside pricing, the observable product cadence has changed character. Heroku still ships updates, but the platform's public roadmap and release pattern over the past several years look like a product in maintenance and consolidation, not one in aggressive expansion. That is an observation about cadence, not a claim about intent. Vendors do not announce declining investment; you infer it from what ships and what does not.
None of this is an accusation. Salesforce is entitled to run Heroku however it chooses. The point is narrower: the platform's owner has demonstrated, publicly and more than once, that it will change pricing and retire product tiers on its own schedule. That is a fact you can plan around.
Most engineering leaders keep a risk register that covers uptime SLAs, data loss, and security incidents. Fewer put platform stewardship on it, and that is the gap this decision lives in. When your entire deploy pipeline, runtime, and data layer sit on one vendor's managed platform, that vendor's pricing direction, feature sunsets, and investment cadence are risks to your business in exactly the same way an outage is. The difference is that an outage lasts hours and a forced migration lasts months.
Run the arithmetic on what a forced migration costs, using your own numbers. Take the engineer weeks required to containerize your apps, re-platform your databases, rebuild your CI, and re-verify production behavior, then multiply by loaded engineering cost, then add the roadmap work that does not ship while that happens. For most teams in the $2M to $50M ARR range, that figure dwarfs a year of hosting spend on any platform. The lesson is not "leave Heroku immediately." The lesson is that the timing of that spend should be your choice, made when your team has slack, not the vendor's choice, made when it does not.
Framed this way, the free-tier retirement matters less as a pricing event and more as a data point about how decisions get made. A platform whose owner has changed the deal before can change it again. Your job is not to predict when; it is to make sure that if it happens, you are executing a plan you already scoped rather than improvising one under deadline.
Honestly: sometimes yes. If your Heroku footprint is a handful of dynos and one Postgres add-on, your monthly bill is small relative to what a migration would cost in engineer time, and you have no compliance requirements pushing data into an account you control, then staying is a defensible decision. The workflow still works. Your team knows it. Migrating a small, cheap, uncomplicated deployment to save a modest monthly sum is often a net loss once you price the engineering hours. A post that pretends otherwise is selling you something; this one will just say it plainly and move on.
The calculus changes when specific tripwires fire. Watch for these:
If none of these fire, stay and revisit in six months. If two or more fire, you should have a scoped migration plan on the shelf even if you do not execute it yet. The plan itself is cheap; the absence of one is what gets expensive.
The fear behind "Heroku exodus" headlines is that leaving means giving up the workflow that made Heroku worth paying for and inheriting a Kubernetes cluster your team is not staffed to run. That is a false choice. Convox provides the same deploy model, git-driven builds, releases, one-command rollbacks, and environment variables managed outside your codebase, but the infrastructure runs on a Rack installed into your own AWS, GCP, Azure, or DigitalOcean account. The workflow survives; the ownership changes. The difference in what that ownership means day to day is laid out in the Convox versus Heroku comparison, but the structural point is simple: when the platform layer runs inside an account you own, a platform vendor's pricing or sunset decision can no longer force a migration. You pay your cloud provider directly for infrastructure, with no markup from Convox on that bill, and the vendor-dependency line item comes off your risk register.
Mechanically, the concepts map more directly than most teams expect. A Procfile's process types become services in a convox.yml manifest. Add-ons like Heroku Postgres and Redis become Resources that inject the same style of connection URL your app already reads. Heroku Scheduler jobs become Timers. A typical Rails app with a web process, a worker, and two add-ons translates to something like this:
environment:
- SECRET_KEY_BASE
- RAILS_ENV=production
resources:
database:
type: postgres
cache:
type: redis
services:
web:
build: .
command: bundle exec rails server -b 0.0.0.0 -p 3000
port: 3000
resources:
- database
- cache
worker:
build: .
command: bundle exec sidekiq
resources:
- database
- cacheDeploys become convox deploy, which builds, creates a release, and promotes it with a rolling update. Rollbacks are convox releases rollback against any previous release, and config changes go through convox env set, which creates a new release the same way Heroku config vars do. See rollbacks and environment variables in the docs for the full behavior.
Name the trade-off, because there is one. If your apps build with Heroku buildpacks, you will write a Dockerfile for each service; that is real one-time work, typically the largest single line item in the migration. And owning your cloud account means owning the relationship with your cloud provider, even though Convox manages the Kubernetes layer underneath so your team does not have to. For teams not ready for a cloud account at all, Convox Cloud Machines offer the same managed workflow on Convox-hosted infrastructure at fixed pricing, from $12 per month for an X-Small machine that includes 250 free hours monthly, up to $150 per month for a Large. Cloud Machines trade account ownership for simplicity; they are the on-ramp, and the BYOC Rack is where the vendor-risk argument fully pays off.
If you want to evaluate the field before committing, the Heroku alternatives overview covers how the ownership models differ, and the step-by-step Heroku to Convox migration guide walks through the Procfile-to-convox.yml translation, data migration, and a DNS cutover sequenced so Heroku keeps serving traffic until the new deployment is verified. The migration documentation covers the same ground in reference form.
No. Heroku is an operational, supported Salesforce product running production applications today, and there is no announced shutdown. The real question is stewardship: the platform has retired product tiers and changed pricing on its own schedule before, which makes it a vendor risk to plan around rather than a platform to panic about.
In August 2022 Heroku announced it would retire free dynos, free Postgres, and free Redis, effective that November, citing a focus on its paid platform. Lower-cost paid plans were introduced in their place. Whatever the reasoning, the retirement demonstrated that pricing and tier decisions happen on the vendor's timeline, not the customer's.
Yes, for the right profile: a small dyno footprint, a bill that is modest relative to migration cost, and no compliance requirements. It becomes a poor fit when hosting costs outgrow revenue, when customers require data in an account you control, or when you depend heavily on add-ons that carry their own vendor risk on top of the platform's.
Convox keeps the git-driven deploy, release, rollback, and environment variable workflow but runs it on infrastructure in your own AWS, GCP, Azure, or DigitalOcean account, which removes platform-vendor dependency entirely. Teams not ready to own a cloud account can start on Convox Cloud Machines, managed hosting with fixed pricing from $12 per month.
The concepts map directly: Procfile process types become convox.yml services, add-ons become linked Resources injecting the same connection URLs, and Scheduler jobs become Timers. The largest one-time cost is writing a Dockerfile if you currently use buildpacks. DNS cuts over last, so Heroku serves production traffic until the new deployment is fully verified.
Your next step is an inventory, not a rewrite. Pull your latest Heroku invoice, list every dyno and add-on, and score the result against the four tripwires above: bill growth versus revenue, compliance pressure, add-on dependency, and scale features you cannot reach. If two or more fire, scope a pilot migration with one app using the migration guide and the Getting Started documentation.
Create a free Convox account to run that pilot on your own schedule, or talk to our team about mapping your Heroku footprint before you commit engineering time.
