It means: go elsewhere, they're dead.

What's the best alternative?

Build.io came out of this exact problem a few years ago (I joined in 25Q4) - trying to be what Heroku could have been if it had continued to evolve.

We offer the same default simplicity/speed, but with the ability to go deeper once teams hit scale, cost, or workflow limits. Plus a pricing model that stays understandable and improves as teams scale rather than punishing them for it.

Fair warning: the website is pretty light right now. It’s mostly a placeholder while we prep a broader push over the few months. Happy to answer questions here if helpful.

Not to be confused with builder.io, or worse, builder.ai

Do you care to show prices? The true benefit of heroku for me was really predictable pricing model. Build.io website doesn’t have it on mobile site at all. I don’t want to look at demo, i want to hook up my credit card, set a monthly budget and explore

llIIllIIllIIl & runako give me an email on steven[at]build.io and I'll share. As mentioned, we stripped the site back while we overhaul and we certainly didn't expect this today!

To be clear, you just answered "Do you care to show prices?" with No.

You’re right - reading that back, it comes across as a “no,” and that wasn’t my intent.

We should show pricing, and we will. We temporarily stripped the site back while overhauling positioning and pricing, which is why it’s missing right now. That’s on us, not a stance against transparency.

In the meantime, I’m more than happy to share pricing directly.

At a high level on our pricing: - Current customers are on a mix of usage-based and fixed monthly plans, depending on their needs. We've found many of our customers love the fixed plan as it's a whole new level of predictability. - We’re generally architected to land well below Heroku’s Enterprise pricing and to be competitive with a IaaS. - We want pricing to get out of your way as you scale, so no big steps in pricing as you add services. - Databases are HA by default and support replication. - Pipelines and review apps don’t require hacks to avoid per-review-app database costs.

Happy to answer specifics here or over email if helpful.

FWIW it doesn't look like pricing or details of the service offerings are available on the desktop site, either.

Moved from heroku to fly.io three years ago and I don’t regret it, great platform occasionally goes down and requires a bit of attention but the support forum is great

I had an issue with one of my Sprites (Fly.io also runs sprites.dev) and the CEO responded to me personally in less than 10 minutes. They got it fixed quickly.

I was a free customer at the time. I pay for it happily now.

It didn't seem quite as fire-and-forget as doing `Heroku create` when I tried to use it 3-4 years ago, especially the database setup. Do you use their Postgres offering?

No my one is a simple ruby sinatra app with no DB. Yeah unfortunately it wasn’t super reliable as heroku but they’re getting better at keeping the instances up

Fly.io are absolute G’s. The product is awesome and the tech blogs they write are fantastic.

If you like VPS, Hetzner with Dokploy. It works great, the UI has essentially all the features of Fly or Render that you'd use for deployment, like preview build URLs and environments.

Very close to the worst alternative for people who actually need Heroku, but it won't stop people from plugging it to death and back.

Eh, no, depends on why you used Heroku in the first place. Way back when, I used it because the UI was dead simple and it Just Worked™. If I can replicate that with a VPS and have a good UI around it that takes care of everything, it's functionally the same to me.

"Depends on what you used it for" applies to just about any platform.

Realistically, self-hosting the PaaS defeats the purpose of a PaaS for the crowd Heroku was attracting.

Heroku was one of the first to have that seamless UX, only after which others like Fly or Render or Railway came to copy it. I wager people were primarily attracted to that user experience and only minimally cared that it was fully hosted versus not, because there was also AWS at that time.

How do you think self-hosting affects that seamless UX they value.

As I said, the correct software on top handles it all for you. I don't think you've actually tried Dokploy.

Dokku is better. And neither is what Heroku's bread and butter customer needs.

But alas, my interest in painstaking explaining why self-hosting is fundamentally incompatible with a product who's value prop was "nothing to install" is waning.

Have a good one.

You and I simply have different opinions on what Heroku's value proposition was, because, again, AWS was also right there and also was "nothing to install." Therefore Heroku was used primarily for its dead simple UX, something which is replicated even in a self-hosted environment, because, again, the value prop was never about PaaS or self-hosting, it was always about the user experience.

Have a good weekend.

Having used Heroku at multiple startups during the 2012–2015 years, this is not correct.

With heroku you could `git push heroku master` and it would do everything else from there. The UX was nice, but that was not the reason people chose it. It was so easy compared to running on EC2 instances with salt or whatever. For simple projects, it was incredible.

That's literally the UX I'm talking about and that's what other companies copied too. To be clear, I'm not (just) talking about how heroku.com looks and works, I'm talking about the entire user experience including git push to deploy, so I believe you are agreeing with me here. That is why I said VPS with Dokploy or Coolify and so on have the same UX, both in the command line with git push deploys supported as well as (now, at least) a vastly superior website user experience, akin to Vercel.

Ok so I am researching what to use in this space - a Vercel-ish clone on cheap VPS - and, is Dokploy really the best option?

What do you think about Caprover? https://github.com/caprover/caprover

Or uh.. Dokku https://github.com/dokku/dokku

Right now I am using Coolify but so far it has not been exactly reliable

I don't like their UIs, Dokploy's is far more modern. And yes Coolify is not known to be very reliable, especially because it's built on PHP.

Check out these videos:

https://youtu.be/ELkPcuO5ebo

https://youtu.be/RoANBROvUeE

Digital Ocean App Engine has the easy setup and GUI management that made Heroku popular.

We saw this coming (like most people) a while ago when Heroku started flaking without status updates, and moved part of our workload to Fly. We ended up moving off Fly as well (significant unreliability and just some very strange network load balancer issues that would cause us downtime) and went to Railway, and that's been fantastic so far. We've moved our whole workload onto it.

Kamal works well

Kamal is basically self hosting though right? So you have to take care of keeping the underlying os patched etc. With heroku you only needed to think about git push.. ?

Holy crap is this underselling how poorly this announcement is structured. Not only does it not provide clarity, it words things in such a way that it just begs more questions. “There are no changes for now”....

"sustaining engineering model"

ie, life support.. bit rot will set in, they are dead.

> including helping organizations build and deploy enterprise-grade AI in a secure and trusted way.

Baffling

It saves face with investors to say you're shuttering a product to focus on the hot new thing as a strategic decision than to say you're shuttering it because your actions have led it to be unviable.

Reminds me of when blockchain was in literally everything. So the wheel turns.

If any Heroku customer is reading this and not immediately going "we need to move off Heroku ASAP" all future problems are their own fault.

That has been the case for a very long time at this point, the Salesforce acquisition was a death knell. The only stuff i have left on Heroku are zombie projects I don't care about.

The Salesforce acquisition closed in 2010, when Heroku was barely three years old.

A whole lot of Heroku's best features shipped after they were acquired. They had a pretty good run under Salesforce for the first few years.

It would be interesting to hear a full oral history of when and where things went wrong after that. I expect the original founders leaving was a major factor.

I think a lot of people are under the misconception that the Salesforce acquisition happened a lot later than it really did. In particular, I think people often implicitly date it to the late-2010s-ish period when Heroku's product emphasis got more visibly enterprisey, and in particular when it started putting integrations with Salesforce's other products front and center.

Honestly if you're still using Heroku today it's because you haven't really caught up with what's going on around you

What's a better offering that makes it easier to push projects in production?

In 2026, every major cloud provider has a service that lets you just hand it a Docker container and let it figure out how to run it.

I loved Heroku, but moved away a couple of years back. Tried 3 major "alternatives" (dokku, Render, Fly.io), and the big clouds, and the only thing that made me happy at the end was Coolify. I do keep Netlify for FE-only projects though.

I get what you're saying but the onus is (and should) definitely be on the company to inform customers - and there's many laws to that effect.

What laws? As long as they fulfill Heroku fulfills the obligation in any contracts they have made, no law has been broken.

If you are paying month to month and actually check the Terms of Services of those services, most of them can shut down instantly without notice as long as they stop billing you.

As a former enterprise person, this clearly states “exiting growth cycle into low-staffing maintenance mode”; Salesforce must have bought them to kill a price-beating competitor to multi-year Salesforce PaaS contracts, same as Okta did with Auth0. Investors are typically-majority short-sighted and only care about growth-cycle revenue, so once they reached market saturation, they were ripe and duly reaped. So long, Heroku.

You are saying the plan was to buy a "price-beating competitor", invest in them for 16 years, and then finally pull the rug out now?

They’re not competition if you own them! Typepad continued for over a decade after it was purchased. Auth0 is still in maintenance mode afaik. It can last as long as revenue pays for the FTE to maintain it, or until corporate reallocated the FTE to higher revenue-per-FTE-hour opportunities.

Auth0 still has a ton of people working on it at Okta. If they’re facing execution problems, it’s not due to a lack of resources.

Auth0 and Okta serves two different market segments. You’d use Autho0 for your customers and Okta for your employees.

That’s why they bought Auth0 in the first place. They didn’t have a real offering for customer identity.

Auth0 is constantly releasing new features, including a new major offering now for AI agents. Plus is still very active in the development community, with open source like OpenFGA, frameworks, contributions to standards and so much more.

Not sure where the maintenance mode is coming from...

Reminds me of https://youtu.be/T2BY8zZ1CTM?si=XDroWqVD-pElN9si

FYI, you forgot to remove the &si= tracking cookie from your derogatory comment that uniquely identifies you. As a former Salesforce/Heroku employee and so presumably familiar with Heroku’s treatment within the megacorp for at least some of (checks notes) the past sixteen years, do you have anything relevant to contribute to this post?

that was great!

First of all, you and me, start workin’ at the bank

Absolutely none of this is true. What was the PaaS Heroku was apparently beating at the time of the acquisition?

Noted. Please accept my apologies and retraction.

Oh, they're very clear, just not explicit.

What's not to get? The product is being bumped down in terms of priority so they can focus on AI word salad solutions. They are waiting for enough customers to end their contracts before they discontinue the product altogether.

Was clear to me. If I was looking at using them, I wouldn’t. If I was already using them, I’d stop. They seem dedicated to supporting the slow extinction so it doesn’t have to be a fire drill exit, but how do you sleep at night knowing they’re playing with matches.

I worked at Pardot around the time Salesforce started using this same language in internal announcements about Pardot.

Our Pardot leadership translated for us and provided the necessary context: Pardot is being killed. The plan was to start building the product that would replace it, stop selling new contracts, rename Pardot in the meantime so the change wouldn't be as noticeable, and in a timeline of "by 10 years from now" Pardot wouldn't exist anymore.

This is Salesforce for "last call for the lifeboats, we're gonna capsize the boat."