As somebody whose first day working at Heroku was the day this acquisition closed, I think it’s mostly a misconception to blame Salesforce for Heroku’s stagnation and eventual irrelevance. Salesforce gave Heroku a ton of funding to build out a vision that was way ahead of its time. Docker didn’t even come out until 2013, AWS didn’t even have multiple regions when it was built. They mostly served as an investor and left us alone to do our thing, or so it seemed those first couple years.
The launch of the multi language Cedar runtime in 2011 led to incredible growth and by 2012 we were drowning in tech debt and scaling challenges. Despite more than tripling our headcount in that first year (~20 to 74) we could not keep up.
Mid 2012 was especially bad as we were severely impacted by two us-east-1 outages just 2 weeks apart. To the extent it wasn’t already, reliability and paying down tech debt became the main focus and I think we went about 18 months between major user-facing platform launches (Europe region and eventually larger sized dynos being the biggest things we eventually shipped after that drought). The organization lost its ability to ship significant changes or maybe never really had that ability at scale.
That time coincided with the founders taking a step back, leaving a loss of leadership and vision that was filled by people more concerned with process than results. I left in 2014 and at that time it already seemed clear to me that the product was basically stalled.
I’m not sure how much of this could have been done better even in hindsight. In theory Salesforce could have taken a more hands on approach early on but I don’t think that could have ended better. They were so far from profitability in late 2010 that they could not stay independent without raising more funding. The venture market in ~2010 was much smaller than a few years later—tiny rounds and low valuations. Had the company spent its pre-acquisition engineering cycles building for scalability & reliability at the expense of product velocity they probably would have never gotten successful.
Even still, it was the most amazing professional experience of my career, full of brilliant and passionate people, and it’s sad to see it end this way.
It remains the greatest engineering team I've ever seen or had the pleasure to be a part of. I was only there from early 2011 to mid 2012 but what I took with me changed me as an engineer. The shear brilliance of the ideas and approaches...I was blessed to witness it. I don't think I can overstate it, though many will think this is all hyperbole. I didn't always agree with the decisions made and I was definitely there when the product stagnation started, but we worked hard to reduce tech debt, build better infrastructure, and improve... but man, the battles we fought. Many fond memories, including the single greatest engineering mistake I've ever seen made, one that I still think about until this day (but will never post in a public forum :)).
I'm just going to chime in here and say thank you, there still really isn't in my mind a comparable offering to heroku's git push and go straight to a reasonable production
I honestly find it a bit nuts, there's offerings that come close, but using them I still get the impression that they've just not put in the time really refining that user interface, so I just wanted to say thank you for the work you and the GP did, it was incredibly helpful and I'm happy to say helped me launch and test a few product offerings as well as some fun ideas
It absolutely boggles my mind that nothing else exists to fill this spot. Fly and others offer varying degrees of easier-than-AWS hosting, but nobody offers true PaaS like Heroku, IMHO.
The Heroku style of PaaS just isn't very interesting to most large businesses that actually pay for things. The world basically moved on to Kubernetes-based products (see Google and Red Hat)--or just shutdown like a lot of Cloud Foundry-based products. Yes, many individuals and smaller shops care more about simplicity but they're generally not willing/able to pay a lot (if anything).
It seems like you’re right, but it’s strange that the data world seems to be moving in the opposite direction, with PaaS products like Snowflake, DataBricks, Microsoft Fabric, even Salesforce’s own Data Cloud eating the world.
PaaS has always been this thing that isn't pure infrastructure or pure hosted software that you use as-is. Salesforce has something over 100K attendees of partners and users to its annual conference. It's always been this in-between thing with a fairly loose definition. I'd argue that Salesforce was long a cross between SaaS (for the users) and PaaS (for developers). You can probably apply the same view to a lot of other company products.
Heroku and Ruby, for me, was the 21st century answer to 'deploying' a PHP site over FTP.
The fact that it required nothing but 'git push heroku master' at the time was incredible, especially for how easy it was to spin up pre-prod environments with it, and how wiring up a database was also trivial.
Every time I come across an infrastructure that is bloated out with k8s, helm charts, and a complex web of cloud resources, all for a service not even running at scale, I look back to the simplicity we used to have.
In 2022 Render increased their prices (which for my team worked out at a doubling of costs) with a one month notice period and the CEO's response to me when I asked him if he thought that was a fair notice period was that it was operationally necessary and he was sorry to see us go.
I completely agree that there's nothing comparable to old-school Heroku, which is crazy. That said, Cloudflare seems promising for some types of projects and I use them for a few things. Anyone using them as a one-stop-shop?
For me Northflank have filled this spot. Though by the time I switched I was already using Docker so can't speak directly to their Heroku Buildpack support.
vercel goes a step further, and (when configured this way) allocates a new hostname (eg feature-branch-add-thingg.app.vercel.example.com) for new branches, to make testing even easier.
I’ve been using Render for close to 5 years, and it’s excellent. I can’t think of anything I use that it doesn’t do as well or better than Heroku did last I checked.
I agree with everything you said, and can only thank the founders for their tremendous insight and willingness to push the limits. The shear number of engineering practices we take for granted today because of something like Heroku boggles my mind.
I am forever grateful for the opportunity to work there and make it an effort to pass on what I learned to others.
> by 2012 we were drowning in tech debt and scaling challenges.
> the greatest engineering team I've ever seen
How do these two things reconcile in your opinion? In my view , doing something quickly is the easy part , good engineering is only needed exactly when you want things to be maintainable and scalable, so the assertions above don’t really make much sense to me.
It is hard to explain the impact of such massive growth over a 2-3 period. New features were coming online while old ones were being abused by overuse. For instance, we launched PostgreSQL in the cloud, something we take for granted today. Not only that, but we offered an insane feature set around "follow" and "forking" that made working with databases seem futuristic.
I remember when we launched that product we went to that year's PGCon and there were people in the crowd angry and dismissive that we would treat data that way. It was actually pretty confrontational. Products like that were being produced while we were also working on migrating away from the initial implementation of the "free tier" (internally called Shen). It took me and a few others months to replace it and ensure we didn't lose data while also making it maintainable. The resulting tool lovingly named "yobuko" ended up remaining for years after that (largely due to the stagnation and turn over).
Anyways, that was just a slice of it. Decisions made today are not always the decisions you wanted to be made tomorrow. Day0 is great, day100 comes with more knowledge and regret. :D
In general, my impression has been that you don't want to architect your solution at first for massive scaling, because:
* You probably aren't going to need it, so putting the effort into scaling means slowing down your delivery of the very features that would make customers want your solution.
* It typically slows down performance of individual features.
* It definitely significant increases the complexity of your solution (and probably the user-facing tooling as well).
* It is difficult to achieve until you have the live traffic to test your approach.
Yeah I think there is a lot of truth here. You can't solve all the problems and in Heroku's case we focused on user experience (internally and externally). Great ideas like "git push heroku main" are game changers, but what happens once that git server is receiving 1000 pushes a minute? Totally different thought process.
Perhaps the thing I would add is that even with the tech debt and scaling problems we still had over a million applications deployed ready for that request to hit them.
Well many of them you may know in that they made their way into so many systems (though arguably without the refined UX of Heroku) but the two that come up the most and I am teaching others:
* The simpler the interface for the user, the more decisions you can make behind the scenes. A good example here is "git push heroku". Not only is that something every user (bot or human) can run, it is also easy to script, protect, and scale. It keeps the surface area small and the abstraction makes the most sense. The code that was behind that push lasted for quite some time, and it was effectively 1-2 Python classes as a service. But once we got the code into our systems, we could do anything with it... and we did. One of the things that blows my mind is that our "slug" (this is what we called the tarballs of code that we put on the runtimes) maker was itself a heroku app. It lived along side everyone else. We were able to reduce our platform down to a few simple pieces (what we called the kernel) and everything else was deployed on top. We benefited from the very things our customers were using.
* NOTE: This one is going to be hard to explain because it is so simple, but when you start thinking about system design in this way the possibilities start to open up right in front of you.
The idea is that everything we do is effectively explained as "input -> filter -> output". Even down to the CPU. But especially when it comes to a platform. With this design mentality we had a logging pipeline that I am still jealous of. We had metrics flowing into dashboards that were everywhere and informed us of our work. We had things like "integration testing" that ran continuously against the platform, all from the users perspective, that allowed us to test features long before they reached the public. All of these things were "input" that we "filtered" in some way to produce "output". When you start using that "output" as "input" and chaining these things together you get to a place where you can design a "kernel" (effectively an API service and a runtime) and start interacting with it to produce a platform.
I remember when we were pairing down services to get to our "kernel" one of the Operations engineers developed our Chef so that an internal engineer needed maybe 5-7 lines of Ruby to deploy their app and get everything they needed. Simple input, that produced a reliable application setup, that could now get us into production faster.
Thanks for sharing your story. Those early days of using Heroku were really enjoyable for me. It felt so promising and simple. I remember explaining the concept to a lot of different people who didn't believe that the deployment model could be that simple and accessible until I showed them.
Then life went on, I bounced around in my career, and forgot about Heroku. Years later I actually suggested it for someone to use for a simple project once and I could practically feel the other developers in the room losing respect for me for even mentioning it. I hadn't looked at it for so long that I didn't realize it had fallen out of favor.
> That time coincided with the founders taking a step back, leaving a loss of leadership and vision that was filled by people more concerned with process than results
This feels all too familiar. All of my enjoyable startup experiences have ended this way: The fast growing, successful startup starts attracting people who look like they should be valuable assets to the company, but they're more interested in things like policies, processes, meetings, and making the status reports look nice than actually shipping and building.
Having been on a bigco team that underwent the same sort of headcount growth in a very short time I have to imagine that "more than tripling our headcount in that first year" was likely more a driver of the inability to keep up than a solution. That's not a knock on the talents of anyone hired; it's just exceedingly difficult to simultaneously grow a team that fast and maintain any kind of velocity regardless of the complexity of the problems you're trying to tackle. The culture and knowledge that enabled the previous team's velocity just gets completely diluted.
FWIW, the team that eventually created "Docker" was working at the same time on dotCloud as a direct Heroku competitor. I remember meeting them at a meet-up in the old Twitter building but couldn't tell you exactly which year that was. Maybe 2010 or 2011?
Yep, that team did great work. I remember having lunch at the Heroku office with the dotCloud team in 2011 or 2012 and also Solomon Hykes demoing Docker to us in our office’s basement before it launched. So much cool stuff was happening back then!
Edit: I have also uploaded it on preservetube when I got interested in what are some wayback machine alternatives (given that wayback machine suggests to not upload videos given storage constraints unless absolutely necessary)
So I found preservetube which is sort of intended for this and uploaded this video on it
I worked with some of the folks from there, and honestly you make it sounds like tech debt is inevitable consequence haunting projects from year one.
I disagree, I think the folks just did a sloppy job of "let's bungee strap it all together" for speed, instead of more serious planning and architecturing. They self-inflicted the tech debt on them and got drowned in the debt interest super fast.
There's someone out there who built the scalable version of Heroku at another garage startup. But we never heard of them because Heroku beat them to market.
As far as the Salesforce acquisition goes, I'd be curious to see who made the decision to put Heroku into maintenance only mode.
I worked for a different part of Salesforce. I don't really feel like Salesforce did a ton of meddling in any of its bigger acquisitions other than maybe Tableau. I think the biggest missed opportunity was potentially creating a more unified experience between all of its subsidiaries. Though, it's hard to call that a failure since they're making tons of money.
It could be a case of post-founder leadership seeing that there's not a lot of room for growth and giving up. That happens a lot in the tech industry.
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."
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.. ?
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.
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 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...
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.
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.
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.
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”....
In a company I used to work for, "sustaining engineering" was the team of developers that handled all of the bugs and issues reported by customers on old-but-still-technically-supported versions of the products. (The ones who worked on current versions of the products where just "engineering.")
So basically heroku will fix whatever is broken, but don't expect any new features or development.
From a business perspective, this means they will not be investing in innovation on the platform anymore. Instead, they will focus their efforts on maintaining the current operations and keeping the lights on.
I don't understand the dismissiveness. I think it's pretty clear. Keeping it going for the current users, but not trying to innovate. It might seem weird in an industry that prizes constant innovation and disruption, but this is a mature thing to do.
Or some kind of twisted brain with a "fake it till you make it! or continue to fake it" attitude. I think people doing that stuff for long enough almost have no other choice but to believe themselves, that they are doing net positive work, otherwise the cognitive dissonance would be too great.
Sustaining is used in Engineering to mean that it's now post-GA and there is no further development. The platform is not End of Life but there are no more features planned.
They meant what they wrote. Merriam-Webster's definition: "to support the weight of"
It means they're transitioning to the absolute minimum to keep it alive and nothing more. That could, in worst cases, mean firing everyone except one guy, or using AI to keep it alive.
This news from Heroku does not come as any surprise to the people that were there (as I was). Lots of moving parts and second guessing (that I won't share), but one thing I will say is: Incentives matter.
The seeds of this outcome were planted years ago when sales comp plans changed. When a sales rep can hit their target by simply converting the way an existing customer gets billed, none of them look for new business. Don't need new leads. Don't need to win competitive deals. But finding new customers and losing opportunities are the only things that signal/drive innovation. But from a budgeting perspective, why increase investment in a product that already hits/exceeds their sales targets?
Over time sales targets get met, but the product doesn't advance. By the time all existing customers that can convert have converted, the product is no longer competitive. Like bankruptcy, it comes gradually, then suddenly.
Most of my career, I've worked for startups and small/medium sized businesses, mostly using Ruby On Rails or Node based stuff for language/frameworks.
In every single company I've worked for in the past 15-20 years in this capacity the biggest focus was to exit heroku as quickly as possible. The reason: Price. You don't get to charge a premium for tooling, especially not when open source tooling exists that lets you use cloud providers without paying "the Heroku Tax".) Is Heroku still using AWS/any cloud provider? They should have rolled their own infrastructure decades ago. Alas, they got bought by a shit show of a company.
(Note: I stopped working in 2023 due to health, and much of my early career was ASP/PHP/.NET)
This is my experience, too. Heroku didn’t stay competitive price-wise with alternatives. And scaling even slightly from the basic dynos quadrupled (or whatever) the price.
Feature and experience-wise, we were always really happy with heroku.
I don’t know if this fits with the “salesforce purchased and let stagnate” narrative that nearly everyone here is pushing.
Heroku got a lot of attention and funding within Salesforce at least for the first few years - they grew from about $1M in ARR when they got acquired, and I think they peaked at around $200M (second hand - so I don't know if part of that was funny-money revenue allocated from Enterprise agreements.)
> Salesforce acquired them and just let it die, baffling.
This is a common misconception, but it's actually not true. The reality is even more bizarre.
Most of Heroku's successful years came after the acquisition, not before. Heroku was acquired extremely early in its lifecycle, and Salesforce does actually bear responsibility for investing in it and making it the powerhouse it became. Most of what people remember as the glory days of Heroku came long after the acquisition. And in fact, at the time of acquisiton, Heroku was nowhere near as competitive as a product as it later became.
It was only much later on that Salesforce began to pull the supports out from underneath it, leaving it to fall behind and become what it is today.
The narrative of "BigCo™ acquires startup, then leaves it to wither and die" is a trope because it is very commonly true, but it's actually not what happened in this particular case.
Nothing to study. A common scenario when a mega corp acquires an incredibly successful startup and then lets it die. Happens more often than not. This is why I chuckle when I see an acquisition and the founders claim "Nothing is changing. We are not going anywhere" . There may be exceptions but the moment a hugely successful company like heroku gets acquired, you know it's most likely game over. To their credit, they survived 15 years after acquisition but barely.
Often "nothing is changing" ends up being more literal than the founders realize or intend. Acquisitions by big companies tend to slow the development to a crawl as development bureaucracy takes over. When a great product is practically frozen in time it stops being great in 5-15 years as the rest of the world passes them by.
They had lightning in a bottle because they had an amazing developer experience… and gave everyone free compute and data transfer.
So much of the value was already delivered in that simple `git push heroku master` which gave you a container + load balancer + a database. The vast majority of people didn’t need more. And of those that were left that did far too few of them were willing to suddenly start paying $32/mo per dyno (you just gave me one for free! I only want one more!) or make the jump to multiple hundreds of dollars for a database.
Read any of the threads about Heroku over the years. The biggest complaint is always “it’s too expensive”. Even when a large percentage of what was on people’s bills were add-ons like databases, new relic, redis, logging, etc (i.e., not Heroku).
And the company I worked for hired a full devops team to save us like 5 grand per month on Heroku, only to end up with a much worse developer experience.
This problem one doesn't have, if one pays attention to devops from the start, maybe keeping 1 or 2 capable devops people, who keep things lean. Problem is of course finding the capable ones with the right mindset to keep things as simple and lean as possible.
The result of suddenly needing to hire devops should be to get a convenient setup, but then do you really still need the whole devops team? And if you don't, then hiring them for limited time might come at a cost (hiring freelancers or consultants).
I remember feeling the same way about Slicehost back in the day after Rackspace acquired them. Loved Slicehost. Not too long after though, Digital Ocean appeared with everything I loved about Slicehost and has kept getting better ever since.
I feel like that's Fly.io now. They took all of the great things about Heroku but also dramatically improved and added new capabilities...while improving on pricing, particularly for lower traffic stuff. Love Fly.
I was working for Slicehost at the time, we were a tiny team working our butts off in a loft office in downtown St. Louis, with a few remote employees.
To my understanding there was a runway-growth problem. Could the founders raise and spend (efficiently) enough money quickly enough to keep the business viable? It would be a big gamble and the alternatives were to shut down (no way!) or sell. So they sold.
Rackspace wanted to take Matt’s and Jason’s know how (plus customer base) and go big, really big! That defocused our efforts a bit, plus there were corporate integration headaches (though not too bad). Eventually Linode, already a competitor, and later Digital Ocean filled the void.
All I can say is thank you. I learned to manage servers because of Slicehost and the articles on it back then.
I remember being excited by the merger because well, Rackspace had such a fantastic reputation at the time. People still tell stories about their service. The Rackspace Cloud was just up against an absolute monster in AWS and never really became competitive.
Thank you for the kind words, brought back some fun and interesting memories. I spent a lot of time helping to write and edit those articles, as did my coworkers, glad they helped you!
Not sure why people love fly.io over all the other competitors so much. I myself prefer render.com, for the simplicity and predictability of their billing, and their deployment model is so intuitive
> They took all of the great things about Heroku but also dramatically improved and added new capabilities
I also love Fly, but they were missing easy managed databases (which always seemed like the main reason to use Heroku to me). And now they have them they're very expensive (even compared to Heroku). Which is a shame because their compute is very cheap.
If there was one thing we would all decide differently here at Fly.io, like if you gave us a time machine, is how we did databases. Someday Kurt and I will write the post about how those decisions came to pass and how they played out.
We're doing Managed Postgres now (MPG), which is what we should have done to begin with, but it took us for-ev-er to get here.
What is there to be studied? Once a company is acquired you bounce. There is usually a two year grace period before you start feeling the pain as a customer, which should give you the time to migrate.
Salesforce, like every large enterprise software company, has a formal (and strict) End of Life process. It starts with an announcement like this indicating End of Sales, then once the contract obligations are met, they can end support, then EoL.
There is no way they can avoid this kind of public notice.
I've had a zombie project running on this for many years now. I used to charge people about $25 for 'lifetime', but there's only about ~10 regular users on it, so I try to keep it alive.
Decided this is the time to make the switch over to AWS. They've been rather painful with cancellation. They required all dynos be downgraded to "Eco". Fine.
But this downgrade also incurred another $5 charge which they now required me to pay to remove the credit card. It's not much, but this is shady af.
The billing language has become increasingly shady over the years. Basic is "~$0.010/hour, Max of $7 per month". Eco is "~$0.005/hour, Flat fee of $5.00/month". But in reality, you're just being charged a flat $7 or $5 either way. Eco is visually shown as the "free" option, except it's not free at all.
I'd love to just keep using Heroku and paying some flat rate; we were talking about putting some more work & funding into the project and maybe scaling it up to thousands of users. But I have no idea what Heroku can actually scale to and how much it costs. AWS etc are also not that clear on costs, but at least their specifications is a little more detailed than "Superior performance for your very large-scale, high traffic app"
Heroku (YC W08) was acquired by Salesforce all the way back in 2010 [0], a little over 15 years ago. A lot of people forget that, and assume the acquisition was somewhat recent.
Pretty illuminating reading the thread from 2010, it was big news at the time.
Wow, I have to admit that I have not heard anyone in the past 2 years or so to be on Heroku so it makes sense. I think they handled it quite well knowing that there most likely have been a steady decline of users.
Generally I would avoid promoting myself but in this situation I think it fits the topic. I'm co-founder of a Platform-as-a-Service based in Europe named Ploi Cloud [0]. We focus on web applications working on NodeJS and PHP but would be open to other platforms if people need it. Heroku has always been a source of inspiration to me so if you are looking for an alternative and care about it having a strong European presence please check it out. (We do have a US location too!)
Tiny nitpick but you may want to localize the pricing page, in the UK we use . as a separator instead of , - thought you were changing €1000/month for one 1 vCPU!
I used to be a fan of Heroku when I started working web apps... The deployments were so easy, but I became numb to the actual task of dealing with the complexities of a deployment, when they killed the free tier I struggled for a while... I work with Rails, and I used to bitch a lot about how hard it was to deploy an app, but in retrospective I kind of thank Salesforce for murdering their own product.
Now I deploy at my leisure with stuff like Dokku, or Kamal, directly on a 5 bucks VM on a fresh Linux box in 10 minutes flat. I wrote a nice web app that wraps around Dokku and manage the stack much in the same way I did before with Heroku... I'm much happier and I learned a ton on the way.
This literally says nothing - are we supposed to infer that they are putting the product into maintenance mode and will no longer be developing new features for it? This is a masterpiece of corporate nullspeech.
Seems strange not to just... say nothing and merely remove any mentions of an enterprise offering from the website.
All this blog post can do is make people nervous and lead to customers moving elsewhere. Revenue will drop, and further compound their desire to not invest in the platform. What's the benefit/upside in publishing such an article?
I find it quite funny that they give themselves maximum marks for transparent pricing. If you go to their pricing page, everything is priced as “per user/month plus compute costs*”. Maybe it’s just because I’m on mobile and the page doesn’t seem to work super well, but reading if I have no idea what those compute costs are and therefore what the actual cost is.
Honestly, this is super fair. I went in expecting to hate-read it (not because I have any issues with Render, they're great, just these X vs. Y competitive posts). But yeah, I think this is a reasonable way to look at it.
Back in the day, Heroku, Stripe, and GitHub were iconic engineering organizations. They had this culture rooted in Unix ethos with a sprinkle of modern minimalism and style that was outstanding. You could really see people give a damn in the careful design and polish of their APIs, docs, primitives, and overall output.
Now Heroku and GitHub have been gutted in spirit by their acquirers, which is such a damn shame for our field. We still have Stripe and Apple to some extent, and maybe some new places, but I personally feel a real sense of loss from Heroku and GitHub exiting their status as places you could admire.
Amongst the people opting for just plain Linux servers Linode was the big name back then. They later got supplanted by DigitalOcean, and both are of course also run into the ground by now.
Digital Ocean is run into the ground? I've been with them for a long time and recently just launched new stuff. Still a pretty nice experience and a pretty decent price.
I could also see them being compared with companies still using venture capital to give stuff away for free. In that case, I'm OK with that tradeoff. I'm not really excited about changing my infrastructure every few years to keep getting a free lunch.
The Digital Ocean app platform I recently migrated to is a lot newer than the "rent a VPS" model that they've had forever. Yes, it's not free like the Vercel and Cloudflare Workers I've also used recently. But it also doesn't force my app into a weird shape or to use their preferred language.
On a continuum where AWS sits at one boring+expensive end of the spectrum, and all the subsidized-pricing "we might not be here tomorrow" PaaSes sit at the other, I like the in-between spot where DO sits.
It already is. Besides dedicated options (which are just as expensive) - those shared cores are so old the performance compared to current line AWS models is so far out that it isn't competitive.
> I could also see them being compared with companies still using venture capital to give stuff away for free. In that case, I'm OK with that tradeoff.
That's not the point. They are more expensive compared to hyperscalers.
I really like Railway, and have deployed many sites with them, but got worried by their recent funding round. At some point those investment bills are going to come due.
> helping organizations build and deploy enterprise-grade AI in a secure and trusted way
> Enterprise Account contracts will no longer be offered to new customers
Seems contradictory or I just don't understand how they do product management.
My opinion: Heroku had its time but then stagnated heavily in keeping up with what was going on around it. With the rise of Container as a Service platforms there now were a multitude of more cost-efficient and flexible alternatives which were comparable to the service Heroku offered.
It's such a shame, because they had one of the best services out there. Being able to push via Git and end up with a running deployment was a killer feature. It may not have been the first (Elastic Beanstalk was way older but when it first came out it was Java only iirc, ick) but it was incredibly popular.
Seeing them now chasing AI as a "me too" after being acquired by Salesforce just shows that huge companies will acquire something then sit on it for years and let it rot.
Yup, their Git Push Deployment was really a killer concept and a huge gateway for people just writing good apps not needing to care about infra and still being able to get a production-ready setup.
Couldn’t agree more. That “git push and you’re live” moment removed a huge amount of accidental complexity, and it’s been the guiding experience behind what we’re building at Build.io.
Even when you build cool things it's respectful not to plant them in HN comments :)
I think the usual solution to this is to talk about cool stuff you've done that is only incidentally relevant to the product you're selling. For example, some detail on how you built a technical system or solved a problem, etc...
Disclaimer: Founder of northflank.com here so very clearly biased. But if you’re looking for an alternative, reach out. If not, all good.
Heroku pioneered what a PaaS could be, alongside Cloud Foundry and others, so I’m genuinely sad to see it go down like this.
We built Northflank because we saw enterprises wanting to deploy workloads in their own VPC with Heroku-level simplicity. Over the past 5 years, our mission has been solving the graduation problem where companies outgrow their PaaS and have to eventually migrate.
Northflank runs in your VPC (AWS/GCP/Azure/OCI) with the same git-push experience. We have customers ranging from small startups to governments and public companies who would've otherwise built their own internal developer platform. They either use Northflank as-is in their own cloud or use our API to build their IDP on top of it.
Most common use cases are preview environments and production workloads. Happy to answer questions and throw in some credits if you're evaluating alternatives.
We've been very happy with Northflank's blend of ease-of-use with configurability when you want it. (We're running BYOC AWS.) Running several workloads and it's the best preview-environment-per-PR setup I've encountered across PaaS options.
I've been incredibly happy with Northflank since moving over a few years ago after Heroku got unreliable. Felt like an upgrade from Heroku and the support and reliability have been great.
Looks like that still has downtime for a Postgres migration- you're suggesting going into maintenance mode and just doing a dump/restore. I've seen that take hours once you hit the terabyte scale, depending on hardware.
I've had pretty good luck setting up logical replication from Heroku to the new provider and having a 10-15 minute maintenance window to catch up once it's in sync. Might be worth considering.
You might also want to add a warning about Postgres versions. There's some old bugs around primary key hash functions that can cause corruption on a migration. I've seen it twice when migrating from Heroku to other vendors.
Sorry, but telling people to take a logical backup of their database, and then download it onto their local work station is insane for a production application. First, a logical backup at any decent scale will fail, and second, I don't even have enough local storage to do that -- even ignoring the compliance issues with downloading a full copy of production data onto a work station.
For a company like Northflank, I'd expect actual production-grade documentation for migrating, not instructions that are only applicable to a toy app.
Some folks want to do that, others want to import a backup directly, some want to spawn a read replica and sync their DB. Different strokes for different folks, all supported on Northflank.
Crunchy Bridge will help you migrate. They did a great job for us. We had a minute or so of downtime to let the read replica catch up and cut across. The team knows Heroku well, and some of them built it. (No affiliation, just a happy customer.)
For a little context. Salesforce changed their enterprise structure, effectively doubling their prices and my guess is many of their larger customers fled the platform. The enterprise pricing organized dynos into blocks and without notice they doubled the minimum block unit you could have. As a result, you ended up paying for dynos you weren't even using because they were now rounding up, sometimes by thousands of dollars worth of dyno blocks. So if you thought Heroku was expensive before, now it just didn't make any financial sense at all. For the other PaaS out there: don't do this.
For those not as well-versed in corporate PR....Salesforce are going to do just the bare minimum to keep the service going until the revenue dries up (or some > 0 $$ threshold where it just doesn't financially make sense to keep it running).
Pour one out for Heroku as they were truly a revelation back in the day and one of the most magical experiences ever on first run.
We've had a bunch of people migrate over from Heroku in the last couple years, especially after they killed the free tier.
The main difference from other alternatives is that you don't write any infrastructure config - you just declare what you need in your code (databases, cron jobs, pubsub, etc) and Encore handles provisioning it in your AWS/GCP account (works locally as well where local is 1:1 to your prod env). So there's no Terraform to maintain or Docker setup to mess with.
If you're looking to move off Heroku it's pretty straightforward, most folks get their app running in an afternoon. Happy to help if you run into anything: https://encore.cloud
Didn't you read the last line of the announcement? They have enterprise AI dollars to chase! Salesforce wants some of them billions. Gotta make up for the 42% their stock price has dipped in the last 12 months.
I remember reading The Twelve-Factor App [1] from the Heroku folks back in the day, and was blown away by how well they understood the problem. Not only that but they had great taste.
I moved things to Render a while back, and then to my own Hetzner server (I built kind of an open source Vercel clone for that reason [2]).
I'm not quite sure any of these platforms are going to be relevant 5 years from now when you can summon your own DevOps AI agent. At the very least it's going to be incredibly difficult to justify the premium on top of AWS.
This blog post is peak comedy. Heroku is half abandoned, I expected the post to be something like "we're sunsetting Heroku" before clicking and what we get instead is about AI.
Why don't they just spin off the company or sell it? Heroku is a well-established brand (despite Salesforce's best efforts) and there are still plenty of customers and hobbyists relying on it today. Its value to the parent company is clearly 0. Give it away and let someone else have a run at it. Keep an ownership stake in case someone does manage to turn it around. Literally zero downside in it.
It supports all the quality of life features like opening a shell via a cli, which I found was one of my favorite parts of Heroku (canine run —myproject /bin/bash)
Been fortunate enough to get a sponsorship from the Portainer folks, which allows me to maintain and develop full time!
I have moved all Rails apps away from Heroku in the last years. It was great 10 years ago, but then became expensive, full of bugs and with terrible support. All our Rails apps (Pushpad, Newsletter.page, etc) are running on Cuber gem + DigitalOcean Kubernetes... In the last years we achieved 100% uptime (five nines), zero subtle bugs and huge cost savings.
They shot themselves in the foot a long time ago and never recovered from that, I guess. I remember back in 2012-13 they made some changes that ghosted their primary ICP - indie devs and startup owners. They made the platform incredibly expensive to run. A lot of us panicked and had to move to other vendors - I in particular chose Google's AppEngine which was hugely under-appreciated at the time and eventually became a GCP consultant. All thanks to Heroku. Some of my other friends switched to Engine Yard (for rails) and the rest just went on to learn how to self host stuff onto EC2 instances. Heroku knowingly or unknowingly made a lot of careers of the present day engineers in AWS and GCP (including myself). So, I am a bit sad to see them in such a situation if I'm being honest.
Yes, I know they had one truly horrible year. But, they righted the ship.
I worked for a company that ran 10bn in revenue, with thousands of users, and Heroku just hummed along. It ran our business.
The benefit to us was the lack of problems that occurred at deploy time. Heroku's orchestration of removing old dynos, adding new dynos, and their network control was spectacular. DB's were updated, or patched, without downtime. It truly was impressive.
We moved to a combination of AWS and on-prem, and the overhead of providing what Heroku previously provided is quite large.
The original Heroku often gets praised here. Rightfully so. It inspired many. We started our PHP PaaS [0] 13 years, ago. Most of the others from that area are long gone. PagodaBox, CloudControl, PhpFog …
Heroku's git-push-to-deploy was magic in 2012. Sad to see it go out like this.
I've been building Frost https://github.com/elitan/frost, open source and self-hosted. Same idea, git push to deploy, automatic SSL, custom domains, but on your own VPS. Docker-native, no vendor lock-in, no pricing surprises.
The angle that's a bit different: it's designed for AI coding agents. Simple config they write correctly, clear errors, no K8s complexity to hallucinate. You give your agent the install URL and it sets up the whole server.
I think it's fair to say that, if not for Heroku, I would not have had a career in software. I learned how to code web apps from books, and had a breakthrough when I discovered Rails (in 2009 I think?). But for the life of me I did not understand how to deploy a Rails app.
I bashed my head against that wall for a while, then found Heroku, and it just worked. That let me ship a product when I barely knew what I was doing, which let me keep building and learning, until eventually I didn't need Heroku anymore. But I still always liked it, because I never enjoyed thinking about infrastructure.
I used Heroku extensively before AWS reached its current level of maturity. Heroku made it incredibly easy to create cool apps. When Salesforce acquired it, and knowing a lot about Salesforce, I expected tight integration to address use cases where Apex is too limited (Apex being Salesforce's native language). There were (and still are) numerous such use cases. Unfortunately, this never materialized, and Salesforce gradually shifted away from a dev-first platform toward click-based config and heavy reliance on middleware for all kind of integrations.
It's been a butchered acquisition and missed opportunities along the way. And now it ends up just like Microsoft's Skype.
It's too late. I loved Heroku, but having 5+ major outages in a single year was unacceptable. The support was abysmal, and transparency was non-existent. After the Salesforce acquisition, we watched the company culture shift, getting worse and worse over the years. We were forced to migrate to AWS. Even though we were high-spend customers, the trust is gone. This post is a nice gesture of transparency, but it's way too fluffy for my taste. Heroku is dead to me, there’s no coming back from this.
I've been using DigitalOcean App Platform for a while now. It's not a 1:1 Heroku replacement, but the git-based deploys, managed DBs, and ability to move to Droplets later without a big migration have worked very well for me.
Digital Ocean App Platform is great. We switched to it from Heroku in 2021. It had some growing pains to start, but has been rock solid since. I can only think of 1 downtime incident that was their fault. They continue to improve the platform too, and are VERY responsive to requests.
I think the "Heroku story" was less about technical limitations, but everything except technical limitations. More than a decade ago, I started learning and building on Heroku and hosted all my side projects and client projects on Heroku. Then when they got acquired, I was naive; then they removed their free tier and that broke my trust.
I primarily worked on PoC/MVP development where I worked to bring ideas to something barely tangible. And Heroku's free tier decisions meant it was a barrier for developers to develop on their platform. Pay first, develop later. It was like the rest of the industry.
After that, I just exited containerized platform-based application development entirely because convenience and having that weird developer philosophy "I must not pay because I can find a way" was less of a reason than sustainability. For me, containerized application platforms was about POC and MVP. If there was growth then me or the client can pay for the convenience. But if there was nothing, pretty easy to delete the project.
Then I committed to replicating the Heroku experience with a small VPS, backing up via rsync, and moving from PostgreSQL to SQLite. I can even charge clients for hosting (+ maintenance) on my VPS.
I do not know, to me containerized application platforms are limited by commercial challenges rather than technical ones. I see tons of containerised application platforms, but the trust has eroded because of a single company.
I have changed my development facility and laid the groundwork to not commit to these platforms. Sustainability over convenience.
Sure, I understand and respect folks at fly.io, render, railway, and even the open source variants of these companies (Caddy etc.). But there is no sustainability guarantee for these platforms. It was not just about the "free tier", to me it transcends to a philosophical point about building applications in general. Sure, there could be a new era with AI making MVP/PoC development easy through hosting in containerised applications, but that is a tangent point.
If Heroku were doing everything right, there would not be a dozen application platforms out there, but they made mistakes and, in my opinion, made the entire containerised application platform model untrustworthy.
Just about to set up a new app to deploy to Heroku, but this does not seem promising. Render seems like the next logical move, but curious where others are looking for alternatives.
I moved to render years ago and have been very happy with the decision. It feels like heroku, if it never got acquired by salesforce and kept improving.
When bandwidth matters, when you don't want to over or under provision, when you need multiple seats: if you make a project with a small team, Render is going to be quite expensive because of the cost of each seat while Railway offers unlimited seats for they paid plans. Just the whole pricing is different, I found myself more leaning into Railway when doing calculations.
Sorry, I wasn't saying you should split, I wanted to say that depending on what type of apps you are more leaning into one makes a bit more sense than the other. Render with their own CDN is quite good for frontend apps. In comparison, the whole config and auto scalling/provisioning of Railway makes it easier for backend app.
Of course you can do both with both of these services.
yes,, render feels like the most natural next step right now (similar mental model). Still kind of nostalgic about Heroku, had really good times with it.
It's nice that they would admit this, but it seems a little strange that they would. Why not just never add new features and let people figure it out on their own? A big statement like this seems more like implicitly killing the platform, which is what they say they aren't doing.
I guess the best way to interpret this is that they are killing the platform over time but they don't want to kill it right now since money is still coming in and it would make too many customers mad.
This is such a weird press release that totally obscures what it's trying to say. Just use clear and concise language and treat your customers like adults.
Watching their public roadmap to see what happens. Right now, it looks about the same as it has for a while: useful new features and expected maintenance, moving along at a reasonable if not blistering clip.
The simplicity it brought at the time to hand-jammed and complex processes was nothing short of exemplary. They set the bar on how streamlined application deployment can be and a great UI to go along with it.
Heroku may die but the ideas Heroku executed on and brought to life will continue to prosper... so long Heroku!
It sounds like there were pretty broad layoffs which impacted a lot more than just a focus on enterprise contracts. It wasn't "just" a few enterprise sales people. Engineering may have indeed been the least impacted, but this sounds like biggest round of layoffs to hit Heroku since its inception, not just some right sizing from over hiring.
One of the worst "engineers" I've suffered working with (spent all day on Slack virtue signaling, put on a PIP) went to Heroku. A comment I made was "only a sinking ship would take them/her." This update from Heroku does not surprise me.
For us, the reason is we're primarily a Salesforce company and rely on the Heroku Connect product to facilitate bidirectional syncing between Salesforce and PostgreSQL (which also requires Heroku PG).
One of the biggest benefits to this product -- aside from the syncing mechanism -- is a bypass of Salesforce's extremely limiting (and expensive) API limits.
All I’m going to say is if your press release is titled “an update on heroku” instead if something exciting it means you aren’t delivering happy news that is good for the user.
I bet I’m right. Haven’t read the article or comments, I’m just posting this comment to see if I’m proven right or wrong.
It really surprises me there isn’t a modern heroku alternative that supports the same.. things.
Like build pipelines, routing included, multiple worker types.
AWS is way less batteries included. And none of the competitors seems to offer the same kind of service, last time I looked.
Thanks for the reply!
Most of these (also on the alternativeto) are self-hosted, which is different from having heroku do it. Also most only support webservers, while the majority of our servers aren't web..
My understanding is that Heroku is just an AWS reseller. I don't know if there's a lot of value in a PaaS piggy-backing on another PaaS anymore. Especially for Salesforce.
Heroku does lots of revenue, even if they pay AWS. I do think it would be worth.. quite a bit. And I would be very happy if a better steward would buy it.
It would be impossible to buy a company as a steward. We worked with them. In the early 2020s, their teams were as lazy as IBM boomers. Happy to hop on a call, but let's do an rain check or whatever and come back to you after 17 weeks to say no in an email CCed with 42 people playing hot potato between commercial people who try their best to sound technical. You need a mind map to know which person you were talking to and who introduced you to them.
My money is on holding companies like IAC buying the brand first through financial engineering and restructuring finances initially. They would load it up with debt like they did with the sporting goods store in Sopranos.
Afterward, they would sell it to a Euro-based caretaking company like Bending Spoons, with a focus on maintenance engineering rather than innovation engineering.
TIL Salesforce acquires Heroku in 2011, way before I was even a CS graduate. I remember enjoying using the free tier of Heroku for my school projects but also the pain of dyno cold starts.
Spinning up temporary VMs/stateful machines is going to be super valuable in the next year or 2. Heroku not jumping on this just shows the state of Salesforce. Absolutely inept. I foresee slack going down a similar path of enshittification
haha we actually launched it today. Point taken though! It's not a video though just an interactive widget. Instead of scrolling you press enter. Once we launch I'm sure we'll have something more traditional
chatgpt translation: Heroku isn’t shutting down, but they’re basically done building new stuff.
For those who want to move and potentially save $ in process, here is a nice cost comparison: https://infraslash.com/costs/
I originally saw this on Twitter/X, the wording here is very confusing. The tl;dr version is simply they are going to be KTLO -keep the lights on- mode.
>> “ we want to be clear about what this means for customers.”
Nope, not clear.
This is a clear message “ the heroku product is cancelled but will not be shut down, will continue to operate exactly as before but no new features will be added.”
In 2018, I had to transition my org at the time from Heroku to AWS (with the org lacking any AWS experience outside of myself).
We ended up with a “Heroku-like” experience. Push to GitHub. Action triggers job. Job packages and deploys. À la carte yaml config for extras like databases and ALBs. It worked pretty well. It was an in house solution to an in house problem.
As somebody whose first day working at Heroku was the day this acquisition closed, I think it’s mostly a misconception to blame Salesforce for Heroku’s stagnation and eventual irrelevance. Salesforce gave Heroku a ton of funding to build out a vision that was way ahead of its time. Docker didn’t even come out until 2013, AWS didn’t even have multiple regions when it was built. They mostly served as an investor and left us alone to do our thing, or so it seemed those first couple years.
The launch of the multi language Cedar runtime in 2011 led to incredible growth and by 2012 we were drowning in tech debt and scaling challenges. Despite more than tripling our headcount in that first year (~20 to 74) we could not keep up.
Mid 2012 was especially bad as we were severely impacted by two us-east-1 outages just 2 weeks apart. To the extent it wasn’t already, reliability and paying down tech debt became the main focus and I think we went about 18 months between major user-facing platform launches (Europe region and eventually larger sized dynos being the biggest things we eventually shipped after that drought). The organization lost its ability to ship significant changes or maybe never really had that ability at scale.
That time coincided with the founders taking a step back, leaving a loss of leadership and vision that was filled by people more concerned with process than results. I left in 2014 and at that time it already seemed clear to me that the product was basically stalled.
I’m not sure how much of this could have been done better even in hindsight. In theory Salesforce could have taken a more hands on approach early on but I don’t think that could have ended better. They were so far from profitability in late 2010 that they could not stay independent without raising more funding. The venture market in ~2010 was much smaller than a few years later—tiny rounds and low valuations. Had the company spent its pre-acquisition engineering cycles building for scalability & reliability at the expense of product velocity they probably would have never gotten successful.
Even still, it was the most amazing professional experience of my career, full of brilliant and passionate people, and it’s sad to see it end this way.
It remains the greatest engineering team I've ever seen or had the pleasure to be a part of. I was only there from early 2011 to mid 2012 but what I took with me changed me as an engineer. The shear brilliance of the ideas and approaches...I was blessed to witness it. I don't think I can overstate it, though many will think this is all hyperbole. I didn't always agree with the decisions made and I was definitely there when the product stagnation started, but we worked hard to reduce tech debt, build better infrastructure, and improve... but man, the battles we fought. Many fond memories, including the single greatest engineering mistake I've ever seen made, one that I still think about until this day (but will never post in a public forum :)).
It was a pleasure working with you bgentry!
I'm just going to chime in here and say thank you, there still really isn't in my mind a comparable offering to heroku's git push and go straight to a reasonable production
I honestly find it a bit nuts, there's offerings that come close, but using them I still get the impression that they've just not put in the time really refining that user interface, so I just wanted to say thank you for the work you and the GP did, it was incredibly helpful and I'm happy to say helped me launch and test a few product offerings as well as some fun ideas
This!
It absolutely boggles my mind that nothing else exists to fill this spot. Fly and others offer varying degrees of easier-than-AWS hosting, but nobody offers true PaaS like Heroku, IMHO.
The Heroku style of PaaS just isn't very interesting to most large businesses that actually pay for things. The world basically moved on to Kubernetes-based products (see Google and Red Hat)--or just shutdown like a lot of Cloud Foundry-based products. Yes, many individuals and smaller shops care more about simplicity but they're generally not willing/able to pay a lot (if anything).
It seems like you’re right, but it’s strange that the data world seems to be moving in the opposite direction, with PaaS products like Snowflake, DataBricks, Microsoft Fabric, even Salesforce’s own Data Cloud eating the world.
PaaS has always been this thing that isn't pure infrastructure or pure hosted software that you use as-is. Salesforce has something over 100K attendees of partners and users to its annual conference. It's always been this in-between thing with a fairly loose definition. I'd argue that Salesforce was long a cross between SaaS (for the users) and PaaS (for developers). You can probably apply the same view to a lot of other company products.
Heroku and Ruby, for me, was the 21st century answer to 'deploying' a PHP site over FTP.
The fact that it required nothing but 'git push heroku master' at the time was incredible, especially for how easy it was to spin up pre-prod environments with it, and how wiring up a database was also trivial.
Every time I come across an infrastructure that is bloated out with k8s, helm charts, and a complex web of cloud resources, all for a service not even running at scale, I look back to the simplicity we used to have.
I find render.com basically as good as Heroku and certainly much better than fly.io's unpredictable pricing
In 2022 Render increased their prices (which for my team worked out at a doubling of costs) with a one month notice period and the CEO's response to me when I asked him if he thought that was a fair notice period was that it was operationally necessary and he was sorry to see us go.
In what way is Fly's pricing unpredictable ?
It varies based on usage
Isn't that how things should be ?
I completely agree that there's nothing comparable to old-school Heroku, which is crazy. That said, Cloudflare seems promising for some types of projects and I use them for a few things. Anyone using them as a one-stop-shop?
For me Northflank have filled this spot. Though by the time I switched I was already using Docker so can't speak directly to their Heroku Buildpack support.
vercel goes a step further, and (when configured this way) allocates a new hostname (eg feature-branch-add-thingg.app.vercel.example.com) for new branches, to make testing even easier.
But their offering is "frontend oriented", what you describe doesn't work for django / laravel / rails / etc, no ?
Have a look at Scalingo, it's a good mix of simplicity and maturity.
https://scalingo.com/blog/heroku-alternative-europe-scalingo...
Yes. We are taking a stab at the entire infrastructure like Heroku did but with a focus on a coding agent-centric workflow: https://specific.dev
I’ve been using Render for close to 5 years, and it’s excellent. I can’t think of anything I use that it doesn’t do as well or better than Heroku did last I checked.
[dead]
I agree with everything you said, and can only thank the founders for their tremendous insight and willingness to push the limits. The shear number of engineering practices we take for granted today because of something like Heroku boggles my mind.
I am forever grateful for the opportunity to work there and make it an effort to pass on what I learned to others.
> by 2012 we were drowning in tech debt and scaling challenges.
> the greatest engineering team I've ever seen
How do these two things reconcile in your opinion? In my view , doing something quickly is the easy part , good engineering is only needed exactly when you want things to be maintainable and scalable, so the assertions above don’t really make much sense to me.
It is hard to explain the impact of such massive growth over a 2-3 period. New features were coming online while old ones were being abused by overuse. For instance, we launched PostgreSQL in the cloud, something we take for granted today. Not only that, but we offered an insane feature set around "follow" and "forking" that made working with databases seem futuristic.
I remember when we launched that product we went to that year's PGCon and there were people in the crowd angry and dismissive that we would treat data that way. It was actually pretty confrontational. Products like that were being produced while we were also working on migrating away from the initial implementation of the "free tier" (internally called Shen). It took me and a few others months to replace it and ensure we didn't lose data while also making it maintainable. The resulting tool lovingly named "yobuko" ended up remaining for years after that (largely due to the stagnation and turn over).
Anyways, that was just a slice of it. Decisions made today are not always the decisions you wanted to be made tomorrow. Day0 is great, day100 comes with more knowledge and regret. :D
In general, my impression has been that you don't want to architect your solution at first for massive scaling, because:
* You probably aren't going to need it, so putting the effort into scaling means slowing down your delivery of the very features that would make customers want your solution.
* It typically slows down performance of individual features.
* It definitely significant increases the complexity of your solution (and probably the user-facing tooling as well).
* It is difficult to achieve until you have the live traffic to test your approach.
Yeah I think there is a lot of truth here. You can't solve all the problems and in Heroku's case we focused on user experience (internally and externally). Great ideas like "git push heroku main" are game changers, but what happens once that git server is receiving 1000 pushes a minute? Totally different thought process.
Perhaps the thing I would add is that even with the tech debt and scaling problems we still had over a million applications deployed ready for that request to hit them.
An organization without “tech debt” is not good at prioritizing.
Yea it seems like not much thought was put into scalability.
Tell us more about some of these ideas and approaches that changed you as an engineer! We'd love to hear!
Well many of them you may know in that they made their way into so many systems (though arguably without the refined UX of Heroku) but the two that come up the most and I am teaching others:
* The simpler the interface for the user, the more decisions you can make behind the scenes. A good example here is "git push heroku". Not only is that something every user (bot or human) can run, it is also easy to script, protect, and scale. It keeps the surface area small and the abstraction makes the most sense. The code that was behind that push lasted for quite some time, and it was effectively 1-2 Python classes as a service. But once we got the code into our systems, we could do anything with it... and we did. One of the things that blows my mind is that our "slug" (this is what we called the tarballs of code that we put on the runtimes) maker was itself a heroku app. It lived along side everyone else. We were able to reduce our platform down to a few simple pieces (what we called the kernel) and everything else was deployed on top. We benefited from the very things our customers were using.
* NOTE: This one is going to be hard to explain because it is so simple, but when you start thinking about system design in this way the possibilities start to open up right in front of you. The idea is that everything we do is effectively explained as "input -> filter -> output". Even down to the CPU. But especially when it comes to a platform. With this design mentality we had a logging pipeline that I am still jealous of. We had metrics flowing into dashboards that were everywhere and informed us of our work. We had things like "integration testing" that ran continuously against the platform, all from the users perspective, that allowed us to test features long before they reached the public. All of these things were "input" that we "filtered" in some way to produce "output". When you start using that "output" as "input" and chaining these things together you get to a place where you can design a "kernel" (effectively an API service and a runtime) and start interacting with it to produce a platform.
I remember when we were pairing down services to get to our "kernel" one of the Operations engineers developed our Chef so that an internal engineer needed maybe 5-7 lines of Ruby to deploy their app and get everything they needed. Simple input, that produced a reliable application setup, that could now get us into production faster.
Anyways, those are just a couple.
Here[0] is a talk that shows off some of these tools. Mark led the way on many of these ideas internally.
[0]: https://www.youtube.com/watch?v=yGcaofDq8SM
Absolutely agree and likewise buddy :)
Thanks for sharing your story. Those early days of using Heroku were really enjoyable for me. It felt so promising and simple. I remember explaining the concept to a lot of different people who didn't believe that the deployment model could be that simple and accessible until I showed them.
Then life went on, I bounced around in my career, and forgot about Heroku. Years later I actually suggested it for someone to use for a simple project once and I could practically feel the other developers in the room losing respect for me for even mentioning it. I hadn't looked at it for so long that I didn't realize it had fallen out of favor.
> That time coincided with the founders taking a step back, leaving a loss of leadership and vision that was filled by people more concerned with process than results
This feels all too familiar. All of my enjoyable startup experiences have ended this way: The fast growing, successful startup starts attracting people who look like they should be valuable assets to the company, but they're more interested in things like policies, processes, meetings, and making the status reports look nice than actually shipping and building.
The cancer of corporations: bureaucracy.
As corporations grow, they also increasingly need some level of process which can increasingly look a lot like bureaucracy.
Bureaucracy is a natural consequence of workforce growth. Respectfully, I think you are blaming the symptoms here, not the root cause.
Having been on a bigco team that underwent the same sort of headcount growth in a very short time I have to imagine that "more than tripling our headcount in that first year" was likely more a driver of the inability to keep up than a solution. That's not a knock on the talents of anyone hired; it's just exceedingly difficult to simultaneously grow a team that fast and maintain any kind of velocity regardless of the complexity of the problems you're trying to tackle. The culture and knowledge that enabled the previous team's velocity just gets completely diluted.
Thanks for a capsule tour through Heroku!
FWIW, the team that eventually created "Docker" was working at the same time on dotCloud as a direct Heroku competitor. I remember meeting them at a meet-up in the old Twitter building but couldn't tell you exactly which year that was. Maybe 2010 or 2011?
Yep, that team did great work. I remember having lunch at the Heroku office with the dotCloud team in 2011 or 2012 and also Solomon Hykes demoing Docker to us in our office’s basement before it launched. So much cool stuff was happening back then!
I remember Solomon's demoing at All Hands... it was such a crazy time for tech and innovation.
Oh hey Curt!! Remember, you are not a monitoring system :)
Haha, funny you should mention that as I was just telling a coworker that story as we worked on a new dashboard for our infrastructure. :D
> people more concerned with process than results
Sounds like something Steve Jobs observed at apple https://youtu.be/l4dCJJFuMsE?si=QOCBUqcUPWu8AsAX
Link with spyware removed: https://youtu.be/l4dCJJFuMsE
I feel as if youtube itself might still contain some tracking.
People recommend invidious and piped but they are starting to have issues.
This video is archived on wayback machine (archive.org) and I feel as if that might be the best way to watch this video right now.
https://web.archive.org/web/20260207024055/https://www.youtu...
Edit: I have also uploaded it on preservetube when I got interested in what are some wayback machine alternatives (given that wayback machine suggests to not upload videos given storage constraints unless absolutely necessary)
So I found preservetube which is sort of intended for this and uploaded this video on it
https://preservetube.com/watch?v=l4dCJJFuMsE
Spyware?
Not OP, but the "si" parameter in the URL is an individual tracking identifier, generated specifically for YouTube to see who you share the link with.
TY
GP means the si url parameter, which is a token that helps google track how their videos are being shared.
I worked with some of the folks from there, and honestly you make it sounds like tech debt is inevitable consequence haunting projects from year one.
I disagree, I think the folks just did a sloppy job of "let's bungee strap it all together" for speed, instead of more serious planning and architecturing. They self-inflicted the tech debt on them and got drowned in the debt interest super fast.
There's someone out there who built the scalable version of Heroku at another garage startup. But we never heard of them because Heroku beat them to market.
Sure, but that bungee strapped slop got them pretty damn far
My point is that they would have gotten much farther. I'm not talking about architecture astronautics, just a little more thinking-ahead.
As far as the Salesforce acquisition goes, I'd be curious to see who made the decision to put Heroku into maintenance only mode.
I worked for a different part of Salesforce. I don't really feel like Salesforce did a ton of meddling in any of its bigger acquisitions other than maybe Tableau. I think the biggest missed opportunity was potentially creating a more unified experience between all of its subsidiaries. Though, it's hard to call that a failure since they're making tons of money.
It could be a case of post-founder leadership seeing that there's not a lot of room for growth and giving up. That happens a lot in the tech industry.
"We know changes like this can raise questions, and we want to be clear about what this means for customers."
Proceeds to not be clear about what this means for customers.
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."
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.
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.
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.
[dead]
"sustaining engineering model"
ie, life support.. bit rot will set in, they are dead.
It means: go elsewhere, they're dead.
What's the best alternative?
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.
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.
Fly.io are absolute G’s. The product is awesome and the tech blogs they write are fantastic.
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
Digital Ocean App Engine has the easy setup and GUI management that made Heroku popular.
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.
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.
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.
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
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.
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
FWIW it doesn't look like pricing or details of the service offerings are available on the desktop site, either.
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.
Not to be confused with builder.io, or worse, builder.ai
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.. ?
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?
First of all, you and me, start workin’ at the bank
Reminds me of https://youtu.be/T2BY8zZ1CTM?si=XDroWqVD-pElN9si
that was great!
[flagged]
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 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...
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.
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.
> 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.
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.
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.
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”....
Oh, they're very clear, just not explicit.
"transitioning to a sustaining engineering model". I don't care what anyone says, it takes real talent to come up with lines like this.
In a company I used to work for, "sustaining engineering" was the team of developers that handled all of the bugs and issues reported by customers on old-but-still-technically-supported versions of the products. (The ones who worked on current versions of the products where just "engineering.")
So basically heroku will fix whatever is broken, but don't expect any new features or development.
From a business perspective, this means they will not be investing in innovation on the platform anymore. Instead, they will focus their efforts on maintaining the current operations and keeping the lights on.
Heroku has been running in this mode for a long time. The only difference is they made it official.
From a business perspective the have brought it out to the field with a shotgun.
As opposed to the relentless innovation they have demonstrated in the past 5+ years? /s
I don't understand the dismissiveness. I think it's pretty clear. Keeping it going for the current users, but not trying to innovate. It might seem weird in an industry that prizes constant innovation and disruption, but this is a mature thing to do.
Could have just said we will Keep the Lights on
This reads more like "we won't deliberately turn the lights off… but they're probably gonna break on their own eventually".
The lights will stay on until they burn out or the power goes off, or someone bumps the light switch or steals the light bulbs.
Or some kind of twisted brain with a "fake it till you make it! or continue to fake it" attitude. I think people doing that stuff for long enough almost have no other choice but to believe themselves, that they are doing net positive work, otherwise the cognitive dissonance would be too great.
I am sure that the guy whose name is on the Post didn't even write this himself. Probably some corporate writer using LLM :).
I would love to see the prompt that led to that word salad
“In standard corporate doublespeak with lots of jargon…“, followed by whatever you want to hand wave away.
We've been optimizing for decades to engineer the bullshit-generating super-soldiers required to craft modern PR statements.
Surely it's a typo and they meant "sustainable"?
Otherwise IMO such an odd word choice. Definition:
>> providing physical or mental strength or support
Sustaining is used in Engineering to mean that it's now post-GA and there is no further development. The platform is not End of Life but there are no more features planned.
They meant what they wrote. Merriam-Webster's definition: "to support the weight of"
It means they're transitioning to the absolute minimum to keep it alive and nothing more. That could, in worst cases, mean firing everyone except one guy, or using AI to keep it alive.
Sustaining as in sustaining their shareholders.
It's what CA/Broadcom does to literally every software product they own.
It's like PBS, they are going to beg for your money now with a sustaining engineering membership
This news from Heroku does not come as any surprise to the people that were there (as I was). Lots of moving parts and second guessing (that I won't share), but one thing I will say is: Incentives matter.
The seeds of this outcome were planted years ago when sales comp plans changed. When a sales rep can hit their target by simply converting the way an existing customer gets billed, none of them look for new business. Don't need new leads. Don't need to win competitive deals. But finding new customers and losing opportunities are the only things that signal/drive innovation. But from a budgeting perspective, why increase investment in a product that already hits/exceeds their sales targets?
Over time sales targets get met, but the product doesn't advance. By the time all existing customers that can convert have converted, the product is no longer competitive. Like bankruptcy, it comes gradually, then suddenly.
Most of my career, I've worked for startups and small/medium sized businesses, mostly using Ruby On Rails or Node based stuff for language/frameworks.
In every single company I've worked for in the past 15-20 years in this capacity the biggest focus was to exit heroku as quickly as possible. The reason: Price. You don't get to charge a premium for tooling, especially not when open source tooling exists that lets you use cloud providers without paying "the Heroku Tax".) Is Heroku still using AWS/any cloud provider? They should have rolled their own infrastructure decades ago. Alas, they got bought by a shit show of a company.
(Note: I stopped working in 2023 due to health, and much of my early career was ASP/PHP/.NET)
This is my experience, too. Heroku didn’t stay competitive price-wise with alternatives. And scaling even slightly from the basic dynos quadrupled (or whatever) the price.
Feature and experience-wise, we were always really happy with heroku.
I don’t know if this fits with the “salesforce purchased and let stagnate” narrative that nearly everyone here is pushing.
Heroku got a lot of attention and funding within Salesforce at least for the first few years - they grew from about $1M in ARR when they got acquired, and I think they peaked at around $200M (second hand - so I don't know if part of that was funny-money revenue allocated from Enterprise agreements.)
The downfall of Heroku should be studied, they had lightning in a bottle and blew it.
Salesforce acquired them and just let it die, baffling.
> Salesforce acquired them and just let it die, baffling.
This is a common misconception, but it's actually not true. The reality is even more bizarre.
Most of Heroku's successful years came after the acquisition, not before. Heroku was acquired extremely early in its lifecycle, and Salesforce does actually bear responsibility for investing in it and making it the powerhouse it became. Most of what people remember as the glory days of Heroku came long after the acquisition. And in fact, at the time of acquisiton, Heroku was nowhere near as competitive as a product as it later became.
It was only much later on that Salesforce began to pull the supports out from underneath it, leaving it to fall behind and become what it is today.
The narrative of "BigCo™ acquires startup, then leaves it to wither and die" is a trope because it is very commonly true, but it's actually not what happened in this particular case.
Nothing to study. A common scenario when a mega corp acquires an incredibly successful startup and then lets it die. Happens more often than not. This is why I chuckle when I see an acquisition and the founders claim "Nothing is changing. We are not going anywhere" . There may be exceptions but the moment a hugely successful company like heroku gets acquired, you know it's most likely game over. To their credit, they survived 15 years after acquisition but barely.
Often "nothing is changing" ends up being more literal than the founders realize or intend. Acquisitions by big companies tend to slow the development to a crawl as development bureaucracy takes over. When a great product is practically frozen in time it stops being great in 5-15 years as the rest of the world passes them by.
Yea, this is accurate in my experience.
Heroku was bought by salesforce when it was only 3 years old.
They had lightning in a bottle because they had an amazing developer experience… and gave everyone free compute and data transfer.
So much of the value was already delivered in that simple `git push heroku master` which gave you a container + load balancer + a database. The vast majority of people didn’t need more. And of those that were left that did far too few of them were willing to suddenly start paying $32/mo per dyno (you just gave me one for free! I only want one more!) or make the jump to multiple hundreds of dollars for a database.
Read any of the threads about Heroku over the years. The biggest complaint is always “it’s too expensive”. Even when a large percentage of what was on people’s bills were add-ons like databases, new relic, redis, logging, etc (i.e., not Heroku).
And the company I worked for hired a full devops team to save us like 5 grand per month on Heroku, only to end up with a much worse developer experience.
This problem one doesn't have, if one pays attention to devops from the start, maybe keeping 1 or 2 capable devops people, who keep things lean. Problem is of course finding the capable ones with the right mindset to keep things as simple and lean as possible.
The result of suddenly needing to hire devops should be to get a convenient setup, but then do you really still need the whole devops team? And if you don't, then hiring them for limited time might come at a cost (hiring freelancers or consultants).
Often seems like there's no defeat that Benioff can't steal from the jaws of Victory.
I remember feeling the same way about Slicehost back in the day after Rackspace acquired them. Loved Slicehost. Not too long after though, Digital Ocean appeared with everything I loved about Slicehost and has kept getting better ever since.
I feel like that's Fly.io now. They took all of the great things about Heroku but also dramatically improved and added new capabilities...while improving on pricing, particularly for lower traffic stuff. Love Fly.
I was working for Slicehost at the time, we were a tiny team working our butts off in a loft office in downtown St. Louis, with a few remote employees.
To my understanding there was a runway-growth problem. Could the founders raise and spend (efficiently) enough money quickly enough to keep the business viable? It would be a big gamble and the alternatives were to shut down (no way!) or sell. So they sold.
Rackspace wanted to take Matt’s and Jason’s know how (plus customer base) and go big, really big! That defocused our efforts a bit, plus there were corporate integration headaches (though not too bad). Eventually Linode, already a competitor, and later Digital Ocean filled the void.
All I can say is thank you. I learned to manage servers because of Slicehost and the articles on it back then.
I remember being excited by the merger because well, Rackspace had such a fantastic reputation at the time. People still tell stories about their service. The Rackspace Cloud was just up against an absolute monster in AWS and never really became competitive.
Thank you for the kind words, brought back some fun and interesting memories. I spent a lot of time helping to write and edit those articles, as did my coworkers, glad they helped you!
Oh those Slicehost articles were excellent. I felt like I could actually do my own sys admin by following them.
Not sure why people love fly.io over all the other competitors so much. I myself prefer render.com, for the simplicity and predictability of their billing, and their deployment model is so intuitive
I think people mostly like the cool balloons Annie draws for us.
> They took all of the great things about Heroku but also dramatically improved and added new capabilities
I also love Fly, but they were missing easy managed databases (which always seemed like the main reason to use Heroku to me). And now they have them they're very expensive (even compared to Heroku). Which is a shame because their compute is very cheap.
If there was one thing we would all decide differently here at Fly.io, like if you gave us a time machine, is how we did databases. Someday Kurt and I will write the post about how those decisions came to pass and how they played out.
We're doing Managed Postgres now (MPG), which is what we should have done to begin with, but it took us for-ev-er to get here.
For what it's worth, I've been very happy using Crunchydata PostgreSQL with Fly.
What is there to be studied? Once a company is acquired you bounce. There is usually a two year grace period before you start feeling the pain as a customer, which should give you the time to migrate.
Salesforce acquired Heroku 15 years ago.
And Heroku has stagnated for at least 13 of those years...
Time flies. I do think the vision lasted pretty long post acquisition, maybe 5 years or so, but then the inevitable seemed... inevitable.
It's just a case of an innovative product that got commodified over time. Not much you can do about that.
Huh? I'm no fan of Salesforce, but they bought Heroku in 2010. That's not "just letting it die."
Downfall? The founders and VCs made tens of millions of dollars. That’s the success condition for them.
It is a typical acquisition by the book, always goes the same way after three to five years.
It was 16 years...
It isn't as if the last years have been anything like everyone deploys Rails on Heroku days.
It took me several reads to distill their post to this one sentence: "Enterprise Account contracts will no longer be offered to new customers"
I'd be glad to stand corrected but AFAICT this is the only sentence that describes the change. All other say "nothing is changing in [some area]".
Trying to downplay something to that extent immediately raises suspicious that this something (the change) is much more profound that what is stated.
Salesforce, like every large enterprise software company, has a formal (and strict) End of Life process. It starts with an announcement like this indicating End of Sales, then once the contract obligations are met, they can end support, then EoL.
There is no way they can avoid this kind of public notice.
I've had a zombie project running on this for many years now. I used to charge people about $25 for 'lifetime', but there's only about ~10 regular users on it, so I try to keep it alive.
Decided this is the time to make the switch over to AWS. They've been rather painful with cancellation. They required all dynos be downgraded to "Eco". Fine.
But this downgrade also incurred another $5 charge which they now required me to pay to remove the credit card. It's not much, but this is shady af.
The billing language has become increasingly shady over the years. Basic is "~$0.010/hour, Max of $7 per month". Eco is "~$0.005/hour, Flat fee of $5.00/month". But in reality, you're just being charged a flat $7 or $5 either way. Eco is visually shown as the "free" option, except it's not free at all.
I'd love to just keep using Heroku and paying some flat rate; we were talking about putting some more work & funding into the project and maybe scaling it up to thousands of users. But I have no idea what Heroku can actually scale to and how much it costs. AWS etc are also not that clear on costs, but at least their specifications is a little more detailed than "Superior performance for your very large-scale, high traffic app"
This may be the worst piece of corporate communication that I've ever seen.
I found myself wondering where the rest of it went.
The balance sheet write-off.
Heroku (YC W08) was acquired by Salesforce all the way back in 2010 [0], a little over 15 years ago. A lot of people forget that, and assume the acquisition was somewhat recent.
Pretty illuminating reading the thread from 2010, it was big news at the time.
0: https://news.ycombinator.com/item?id=1982489
This is surprising to me. I actively used Heroku during the early to mid 2010s. I do not remember ever seeing the Salesforce logo there much later.
Salesforce mostly left Heroku to do its own thing for a long time. Since that changed, dumpster fire.
Wow, I have to admit that I have not heard anyone in the past 2 years or so to be on Heroku so it makes sense. I think they handled it quite well knowing that there most likely have been a steady decline of users.
Generally I would avoid promoting myself but in this situation I think it fits the topic. I'm co-founder of a Platform-as-a-Service based in Europe named Ploi Cloud [0]. We focus on web applications working on NodeJS and PHP but would be open to other platforms if people need it. Heroku has always been a source of inspiration to me so if you are looking for an alternative and care about it having a strong European presence please check it out. (We do have a US location too!)
0: https://ploi.cloud
Tiny nitpick but you may want to localize the pricing page, in the UK we use . as a separator instead of , - thought you were changing €1000/month for one 1 vCPU!
Appreciate the suggestion, thank you! Definitely not charging that much :-)
is this linked with Ploi.io?
Separate companies but Dennis (founder of Ploi.io) is the other co-founder, so indirectly linked. :)
I used to be a fan of Heroku when I started working web apps... The deployments were so easy, but I became numb to the actual task of dealing with the complexities of a deployment, when they killed the free tier I struggled for a while... I work with Rails, and I used to bitch a lot about how hard it was to deploy an app, but in retrospective I kind of thank Salesforce for murdering their own product.
Now I deploy at my leisure with stuff like Dokku, or Kamal, directly on a 5 bucks VM on a fresh Linux box in 10 minutes flat. I wrote a nice web app that wraps around Dokku and manage the stack much in the same way I did before with Heroku... I'm much happier and I learned a ton on the way.
I've been using Coolify for deploying my webapps for about 3 years, it has a good web UI.
This literally says nothing - are we supposed to infer that they are putting the product into maintenance mode and will no longer be developing new features for it? This is a masterpiece of corporate nullspeech.
> with an emphasis on maintaining quality and operational excellence rather than introducing new features
it sounds pretty clear that it's in maintenance mode
It’s clear enough but they aren’t going out of their way to make it obvious. It’s definitely fluffed up / corporately sanitized.
Damage control to limit the rush for the exits?
Seems strange not to just... say nothing and merely remove any mentions of an enterprise offering from the website.
All this blog post can do is make people nervous and lead to customers moving elsewhere. Revenue will drop, and further compound their desire to not invest in the platform. What's the benefit/upside in publishing such an article?
> lead to customers moving elsewhere
Since they're no longer accepting new enterprise clients, maybe this is intentional.
Then why mince words, and why accept new non-enterprise clients - just be clear it's maintenance-only and existing customer-only.
I think they’d be happy if all the customers moved on. They just don’t want to upset enterprise customers.
This is a sad day. I used heroku for years (in the past).
A few alternatives to consider
- https://render.com/ - this is very close to heroku
- https://coolify.io/ - My personal favorite. It's slightly more involved, but you can run it on any hardware like hetzner and save a boatload.
How does render compare to fly.io? Does anyone has experience running production rails apps on these?
https://render.com/articles/render-vs-fly-io
I find it quite funny that they give themselves maximum marks for transparent pricing. If you go to their pricing page, everything is priced as “per user/month plus compute costs*”. Maybe it’s just because I’m on mobile and the page doesn’t seem to work super well, but reading if I have no idea what those compute costs are and therefore what the actual cost is.
Honestly, this is super fair. I went in expecting to hate-read it (not because I have any issues with Render, they're great, just these X vs. Y competitive posts). But yeah, I think this is a reasonable way to look at it.
Thank you! Can't believe I missed that..
https://railway.com is another good one
Back in the day, Heroku, Stripe, and GitHub were iconic engineering organizations. They had this culture rooted in Unix ethos with a sprinkle of modern minimalism and style that was outstanding. You could really see people give a damn in the careful design and polish of their APIs, docs, primitives, and overall output.
Now Heroku and GitHub have been gutted in spirit by their acquirers, which is such a damn shame for our field. We still have Stripe and Apple to some extent, and maybe some new places, but I personally feel a real sense of loss from Heroku and GitHub exiting their status as places you could admire.
Amongst the people opting for just plain Linux servers Linode was the big name back then. They later got supplanted by DigitalOcean, and both are of course also run into the ground by now.
Digital Ocean is run into the ground? I've been with them for a long time and recently just launched new stuff. Still a pretty nice experience and a pretty decent price.
Yes, they haven’t updated their infrastructure in a long time. Pricing hence isn’t competitive.
With each new generation they fall behind.
Maybe? I could see that happening.
I could also see them being compared with companies still using venture capital to give stuff away for free. In that case, I'm OK with that tradeoff. I'm not really excited about changing my infrastructure every few years to keep getting a free lunch.
The Digital Ocean app platform I recently migrated to is a lot newer than the "rent a VPS" model that they've had forever. Yes, it's not free like the Vercel and Cloudflare Workers I've also used recently. But it also doesn't force my app into a weird shape or to use their preferred language.
On a continuum where AWS sits at one boring+expensive end of the spectrum, and all the subsidized-pricing "we might not be here tomorrow" PaaSes sit at the other, I like the in-between spot where DO sits.
> Maybe? I could see that happening.
It already is. Besides dedicated options (which are just as expensive) - those shared cores are so old the performance compared to current line AWS models is so far out that it isn't competitive.
> I could also see them being compared with companies still using venture capital to give stuff away for free. In that case, I'm OK with that tradeoff.
That's not the point. They are more expensive compared to hyperscalers.
The corporate speak is crazy. I think the update boils down to this sentence:
> Enterprise Account contracts will no longer be offered to new customers
Yeah I agree. I saw someone say that they were not in KTLO mode, but this seems pretty bad, especially considering it happening at Salesforce.
Railway is the spiritual successor. Fly is great too. I highly recommend both.
I really like Railway, and have deployed many sites with them, but got worried by their recent funding round. At some point those investment bills are going to come due.
What is the concern exactly? (Product/platform enshittification?)
> helping organizations build and deploy enterprise-grade AI in a secure and trusted way
> Enterprise Account contracts will no longer be offered to new customers
Seems contradictory or I just don't understand how they do product management.
My opinion: Heroku had its time but then stagnated heavily in keeping up with what was going on around it. With the rise of Container as a Service platforms there now were a multitude of more cost-efficient and flexible alternatives which were comparable to the service Heroku offered.
It's such a shame, because they had one of the best services out there. Being able to push via Git and end up with a running deployment was a killer feature. It may not have been the first (Elastic Beanstalk was way older but when it first came out it was Java only iirc, ick) but it was incredibly popular.
Seeing them now chasing AI as a "me too" after being acquired by Salesforce just shows that huge companies will acquire something then sit on it for years and let it rot.
Yup, their Git Push Deployment was really a killer concept and a huge gateway for people just writing good apps not needing to care about infra and still being able to get a production-ready setup.
Couldn’t agree more. That “git push and you’re live” moment removed a huge amount of accidental complexity, and it’s been the guiding experience behind what we’re building at Build.io.
Even when you build cool things it's respectful not to plant them in HN comments :)
I think the usual solution to this is to talk about cool stuff you've done that is only incidentally relevant to the product you're selling. For example, some detail on how you built a technical system or solved a problem, etc...
Translation: We're going to reassign the engineers into Salesforce AI.
I thought if you were all in on AI you wouldn’t need engineers - just swarms of agents doing everything. :)
Huh, so that's what they mean when using the word "we". "We" is not Heroku, it's Salesforce.
Disclaimer: Founder of northflank.com here so very clearly biased. But if you’re looking for an alternative, reach out. If not, all good.
Heroku pioneered what a PaaS could be, alongside Cloud Foundry and others, so I’m genuinely sad to see it go down like this.
We built Northflank because we saw enterprises wanting to deploy workloads in their own VPC with Heroku-level simplicity. Over the past 5 years, our mission has been solving the graduation problem where companies outgrow their PaaS and have to eventually migrate.
Northflank runs in your VPC (AWS/GCP/Azure/OCI) with the same git-push experience. We have customers ranging from small startups to governments and public companies who would've otherwise built their own internal developer platform. They either use Northflank as-is in their own cloud or use our API to build their IDP on top of it.
Most common use cases are preview environments and production workloads. Happy to answer questions and throw in some credits if you're evaluating alternatives.
We've been very happy with Northflank's blend of ease-of-use with configurability when you want it. (We're running BYOC AWS.) Running several workloads and it's the best preview-environment-per-PR setup I've encountered across PaaS options.
I've been incredibly happy with Northflank since moving over a few years ago after Heroku got unreliable. Felt like an upgrade from Heroku and the support and reliability have been great.
Do you have any public docs on how y'all migrate customers out of Heroku Postgres without downtime?
Seems to be the sticking point for a lot of people, myself included.
hey!
northflank supports the same buildpacks that you run on Heroku, so it should be fairly straightforward.
we have these docs for a more detailed walkthrough:
1/ https://northflank.com/docs/v1/application/migrate-from-hero...
2/ https://northflank.com/blog/how-to-migrate-from-heroku-a-ste...
Looks like that still has downtime for a Postgres migration- you're suggesting going into maintenance mode and just doing a dump/restore. I've seen that take hours once you hit the terabyte scale, depending on hardware.
I've had pretty good luck setting up logical replication from Heroku to the new provider and having a 10-15 minute maintenance window to catch up once it's in sync. Might be worth considering.
You might also want to add a warning about Postgres versions. There's some old bugs around primary key hash functions that can cause corruption on a migration. I've seen it twice when migrating from Heroku to other vendors.
Bucardo would be an option: https://www.porter.run/blog/migrating-postgres-from-heroku-t...
Sorry, but telling people to take a logical backup of their database, and then download it onto their local work station is insane for a production application. First, a logical backup at any decent scale will fail, and second, I don't even have enough local storage to do that -- even ignoring the compliance issues with downloading a full copy of production data onto a work station.
For a company like Northflank, I'd expect actual production-grade documentation for migrating, not instructions that are only applicable to a toy app.
I agree, I wouldn't either. You can import directly via a DB to DB import in the platform without involving your laptop.
https://northflank.com/docs/v1/application/databases-and-per....
Some folks want to do that, others want to import a backup directly, some want to spawn a read replica and sync their DB. Different strokes for different folks, all supported on Northflank.
Crunchy Bridge will help you migrate. They did a great job for us. We had a minute or so of downtime to let the read replica catch up and cut across. The team knows Heroku well, and some of them built it. (No affiliation, just a happy customer.)
For a little context. Salesforce changed their enterprise structure, effectively doubling their prices and my guess is many of their larger customers fled the platform. The enterprise pricing organized dynos into blocks and without notice they doubled the minimum block unit you could have. As a result, you ended up paying for dynos you weren't even using because they were now rounding up, sometimes by thousands of dollars worth of dyno blocks. So if you thought Heroku was expensive before, now it just didn't make any financial sense at all. For the other PaaS out there: don't do this.
For those not as well-versed in corporate PR....Salesforce are going to do just the bare minimum to keep the service going until the revenue dries up (or some > 0 $$ threshold where it just doesn't financially make sense to keep it running).
Pour one out for Heroku as they were truly a revelation back in the day and one of the most magical experiences ever on first run.
I work at Encore so I'm biased.
We've had a bunch of people migrate over from Heroku in the last couple years, especially after they killed the free tier.
The main difference from other alternatives is that you don't write any infrastructure config - you just declare what you need in your code (databases, cron jobs, pubsub, etc) and Encore handles provisioning it in your AWS/GCP account (works locally as well where local is 1:1 to your prod env). So there's no Terraform to maintain or Docker setup to mess with.
If you're looking to move off Heroku it's pretty straightforward, most folks get their app running in an afternoon. Happy to help if you run into anything: https://encore.cloud
It's a bit surprising, one would have thought that with the event of accessible coding through agents, such site deployment sites would prosper.
Didn't you read the last line of the announcement? They have enterprise AI dollars to chase! Salesforce wants some of them billions. Gotta make up for the 42% their stock price has dipped in the last 12 months.
Exactly this. Missed opportunity.
I remember reading The Twelve-Factor App [1] from the Heroku folks back in the day, and was blown away by how well they understood the problem. Not only that but they had great taste.
I moved things to Render a while back, and then to my own Hetzner server (I built kind of an open source Vercel clone for that reason [2]).
I'm not quite sure any of these platforms are going to be relevant 5 years from now when you can summon your own DevOps AI agent. At the very least it's going to be incredibly difficult to justify the premium on top of AWS.
1: https://www.12factor.net/
2: https://devpu.sh
Sad day. Was such an amazing product and gave a start to so many companies back then.
It was the easiest place to host my Rails apps back in the day.
This blog post is peak comedy. Heroku is half abandoned, I expected the post to be something like "we're sunsetting Heroku" before clicking and what we get instead is about AI.
They are discontinuing it, you were right.
Here is an article that explains it better - https://www.salesforceben.com/salesforce-shuts-down-heroku-e...
Stolen from https://www.reddit.com/r/webdev/s/6U8jJJRzBC
Why don't they just spin off the company or sell it? Heroku is a well-established brand (despite Salesforce's best efforts) and there are still plenty of customers and hobbyists relying on it today. Its value to the parent company is clearly 0. Give it away and let someone else have a run at it. Keep an ownership stake in case someone does manage to turn it around. Literally zero downside in it.
> Literally zero downside in it.
Any poor valuation or negative news can tank the stock price harder than dealing with it privately.
Sometimes it's best to just let things die.
I’ve been developing an open source Heroku alternative so we may never again be gouged for nice deployment pipelines.
https://canine.sh
It supports all the quality of life features like opening a shell via a cli, which I found was one of my favorite parts of Heroku (canine run —myproject /bin/bash)
Been fortunate enough to get a sponsorship from the Portainer folks, which allows me to maintain and develop full time!
I have moved all Rails apps away from Heroku in the last years. It was great 10 years ago, but then became expensive, full of bugs and with terrible support. All our Rails apps (Pushpad, Newsletter.page, etc) are running on Cuber gem + DigitalOcean Kubernetes... In the last years we achieved 100% uptime (five nines), zero subtle bugs and huge cost savings.
Any write up on this?
so EOL announcement without saying when it will be, but eventually.
we've been loyal heroku customers for over a decade. should have switched off long ago, but as a small team, it was too valuable. such a shame.
They shot themselves in the foot a long time ago and never recovered from that, I guess. I remember back in 2012-13 they made some changes that ghosted their primary ICP - indie devs and startup owners. They made the platform incredibly expensive to run. A lot of us panicked and had to move to other vendors - I in particular chose Google's AppEngine which was hugely under-appreciated at the time and eventually became a GCP consultant. All thanks to Heroku. Some of my other friends switched to Engine Yard (for rails) and the rest just went on to learn how to self host stuff onto EC2 instances. Heroku knowingly or unknowingly made a lot of careers of the present day engineers in AWS and GCP (including myself). So, I am a bit sad to see them in such a situation if I'm being honest.
It was such a great product.
Yes, I know they had one truly horrible year. But, they righted the ship.
I worked for a company that ran 10bn in revenue, with thousands of users, and Heroku just hummed along. It ran our business.
The benefit to us was the lack of problems that occurred at deploy time. Heroku's orchestration of removing old dynos, adding new dynos, and their network control was spectacular. DB's were updated, or patched, without downtime. It truly was impressive.
We moved to a combination of AWS and on-prem, and the overhead of providing what Heroku previously provided is quite large.
I'll remember it fondly, and miss it a bit too.
The original Heroku often gets praised here. Rightfully so. It inspired many. We started our PHP PaaS [0] 13 years, ago. Most of the others from that area are long gone. PagodaBox, CloudControl, PhpFog …
[0] https://www.fortrabbit.com
Heroku's git-push-to-deploy was magic in 2012. Sad to see it go out like this.
I've been building Frost https://github.com/elitan/frost, open source and self-hosted. Same idea, git push to deploy, automatic SSL, custom domains, but on your own VPS. Docker-native, no vendor lock-in, no pricing surprises.
The angle that's a bit different: it's designed for AI coding agents. Simple config they write correctly, clear errors, no K8s complexity to hallucinate. You give your agent the install URL and it sets up the whole server.
Sad, although I guess I'm not surprised.
I think it's fair to say that, if not for Heroku, I would not have had a career in software. I learned how to code web apps from books, and had a breakthrough when I discovered Rails (in 2009 I think?). But for the life of me I did not understand how to deploy a Rails app.
I bashed my head against that wall for a while, then found Heroku, and it just worked. That let me ship a product when I barely knew what I was doing, which let me keep building and learning, until eventually I didn't need Heroku anymore. But I still always liked it, because I never enjoyed thinking about infrastructure.
RIP Heroku, you were legendary.
I used Heroku extensively before AWS reached its current level of maturity. Heroku made it incredibly easy to create cool apps. When Salesforce acquired it, and knowing a lot about Salesforce, I expected tight integration to address use cases where Apex is too limited (Apex being Salesforce's native language). There were (and still are) numerous such use cases. Unfortunately, this never materialized, and Salesforce gradually shifted away from a dev-first platform toward click-based config and heavy reliance on middleware for all kind of integrations.
It's been a butchered acquisition and missed opportunities along the way. And now it ends up just like Microsoft's Skype.
It's too late. I loved Heroku, but having 5+ major outages in a single year was unacceptable. The support was abysmal, and transparency was non-existent. After the Salesforce acquisition, we watched the company culture shift, getting worse and worse over the years. We were forced to migrate to AWS. Even though we were high-spend customers, the trust is gone. This post is a nice gesture of transparency, but it's way too fluffy for my taste. Heroku is dead to me, there’s no coming back from this.
I've been using DigitalOcean App Platform for a while now. It's not a 1:1 Heroku replacement, but the git-based deploys, managed DBs, and ability to move to Droplets later without a big migration have worked very well for me.
Digital Ocean App Platform is great. We switched to it from Heroku in 2021. It had some growing pains to start, but has been rock solid since. I can only think of 1 downtime incident that was their fault. They continue to improve the platform too, and are VERY responsive to requests.
Yeah, I moved a while back to DO's App Platform. I've not had any issues with them so far. Recommend them a lot.
I am considering DO App Platform for a new project. Would you be open to sharing any lessons learned ?
I think the "Heroku story" was less about technical limitations, but everything except technical limitations. More than a decade ago, I started learning and building on Heroku and hosted all my side projects and client projects on Heroku. Then when they got acquired, I was naive; then they removed their free tier and that broke my trust.
I primarily worked on PoC/MVP development where I worked to bring ideas to something barely tangible. And Heroku's free tier decisions meant it was a barrier for developers to develop on their platform. Pay first, develop later. It was like the rest of the industry.
After that, I just exited containerized platform-based application development entirely because convenience and having that weird developer philosophy "I must not pay because I can find a way" was less of a reason than sustainability. For me, containerized application platforms was about POC and MVP. If there was growth then me or the client can pay for the convenience. But if there was nothing, pretty easy to delete the project.
Then I committed to replicating the Heroku experience with a small VPS, backing up via rsync, and moving from PostgreSQL to SQLite. I can even charge clients for hosting (+ maintenance) on my VPS.
I do not know, to me containerized application platforms are limited by commercial challenges rather than technical ones. I see tons of containerised application platforms, but the trust has eroded because of a single company.
I have changed my development facility and laid the groundwork to not commit to these platforms. Sustainability over convenience.
Sure, I understand and respect folks at fly.io, render, railway, and even the open source variants of these companies (Caddy etc.). But there is no sustainability guarantee for these platforms. It was not just about the "free tier", to me it transcends to a philosophical point about building applications in general. Sure, there could be a new era with AI making MVP/PoC development easy through hosting in containerised applications, but that is a tangent point.
If Heroku were doing everything right, there would not be a dozen application platforms out there, but they made mistakes and, in my opinion, made the entire containerised application platform model untrustworthy.
Reading the blog post, I thought I wasn't good at English. Well, I am a non-native English speaker.
Reading the comments, it turns out the blog post says nothing.
Reading the between lines, Heroku is being deprecated.
Just about to set up a new app to deploy to Heroku, but this does not seem promising. Render seems like the next logical move, but curious where others are looking for alternatives.
I moved to render years ago and have been very happy with the decision. It feels like heroku, if it never got acquired by salesforce and kept improving.
Railway for backend APIs. Render for front-end apps. That's my current go-to.
Although I would consider, _when possible_, using Vercel or Netlify.
Why/when do you use Railway over Render?
When bandwidth matters, when you don't want to over or under provision, when you need multiple seats: if you make a project with a small team, Render is going to be quite expensive because of the cost of each seat while Railway offers unlimited seats for they paid plans. Just the whole pricing is different, I found myself more leaning into Railway when doing calculations.
why split, you could use railway and render for both front end and back end
Sorry, I wasn't saying you should split, I wanted to say that depending on what type of apps you are more leaning into one makes a bit more sense than the other. Render with their own CDN is quite good for frontend apps. In comparison, the whole config and auto scalling/provisioning of Railway makes it easier for backend app.
Of course you can do both with both of these services.
Yes, Render if you want something similar.
yes,, render feels like the most natural next step right now (similar mental model). Still kind of nostalgic about Heroku, had really good times with it.
It's nice that they would admit this, but it seems a little strange that they would. Why not just never add new features and let people figure it out on their own? A big statement like this seems more like implicitly killing the platform, which is what they say they aren't doing.
I guess the best way to interpret this is that they are killing the platform over time but they don't want to kill it right now since money is still coming in and it would make too many customers mad.
This is such a weird press release that totally obscures what it's trying to say. Just use clear and concise language and treat your customers like adults.
Why do they not sell it? Why do companies just close down products and services without ever exploring a sale possiblity?
Watching their public roadmap to see what happens. Right now, it looks about the same as it has for a while: useful new features and expected maintenance, moving along at a reasonable if not blistering clip.
https://github.com/orgs/heroku/projects/130
The simplicity it brought at the time to hand-jammed and complex processes was nothing short of exemplary. They set the bar on how streamlined application deployment can be and a great UI to go along with it.
Heroku may die but the ideas Heroku executed on and brought to life will continue to prosper... so long Heroku!
It sounds like there were pretty broad layoffs which impacted a lot more than just a focus on enterprise contracts. It wasn't "just" a few enterprise sales people. Engineering may have indeed been the least impacted, but this sounds like biggest round of layoffs to hit Heroku since its inception, not just some right sizing from over hiring.
Not at all surprising, but a real shame. Nothing that I know of has come close to the ease of the "Deploy to Heroku" button.
There's very little written history about Heroku but there is this podcast
The Story Of Heroku With Adam Wiggins, co-founder and former CTO of Heroku.
https://open.spotify.com/episode/3nEwB6apkvUpwk8W9KgzEF
One of the worst "engineers" I've suffered working with (spent all day on Slack virtue signaling, put on a PIP) went to Heroku. A comment I made was "only a sinking ship would take them/her." This update from Heroku does not surprise me.
Comment adds nothing valuable to the discussion. Hope you at least feel better now.
Comment adds nothing valuable to the discussion. Hope you at least feel better now.
As someone that migrated off of Heroku back in 2023 for a monitoring start-up - why were you still on Heroku?!
For us, the reason is we're primarily a Salesforce company and rely on the Heroku Connect product to facilitate bidirectional syncing between Salesforce and PostgreSQL (which also requires Heroku PG).
One of the biggest benefits to this product -- aside from the syncing mechanism -- is a bypass of Salesforce's extremely limiting (and expensive) API limits.
All I’m going to say is if your press release is titled “an update on heroku” instead if something exciting it means you aren’t delivering happy news that is good for the user.
I bet I’m right. Haven’t read the article or comments, I’m just posting this comment to see if I’m proven right or wrong.
So they are going into maintenance mode?
It really surprises me there isn’t a modern heroku alternative that supports the same.. things. Like build pipelines, routing included, multiple worker types. AWS is way less batteries included. And none of the competitors seems to offer the same kind of service, last time I looked.
I think there's a couple decent alternatives out there: https://alternativeto.net/software/heroku/
There are also a lot of cool "self-hosted Heroku" alternatives
- Coolify (PHP) (2020) https://github.com/coollabsio/coolify
- Dokku (Go) (2013) https://github.com/dokku/dokku
- Dokploy (TypeScript) (2024) https://github.com/Dokploy/dokploy
- CapRover (TypeScript) (2017) https://github.com/caprover/caprover
- Komodo (Rust) (2022) https://github.com/moghtech/komodo
Literally nobody who seriously uses Heroku wants to self-host their own Heroku.
We had an enterprise account on Heroku. We invested a little in Dokku and moved to self host it as of a few months ago.
We now have a kubernetes (k3s) backed Dokku self hosted on Hetzner. Significantly cheaper but pretty robust.
Just saying that it's not literally, but you are right, most people wouldn't be interested in self hosting.
What DO you want?
Thanks for the reply! Most of these (also on the alternativeto) are self-hosted, which is different from having heroku do it. Also most only support webservers, while the majority of our servers aren't web..
northflank comes close
When I was young, the startup company I was at used heroku for fast deploys.
We eventually migrated to AWS directly, because Heroku basically exploits you.
Now I'd probably use Fly IO if not just a lambda with AWS gateway.
I don't like building backends and will avoid doing so if possible.
I wonder how much money Salesforce would need to sell what's left of Heroku to a better steward.
My understanding is that Heroku is just an AWS reseller. I don't know if there's a lot of value in a PaaS piggy-backing on another PaaS anymore. Especially for Salesforce.
I don't see AWS as a PaaS at all. Heroku's selling point has always been how it makes everything way easier.
There's a ton of value right now in the existing customers. None of them want to put effort into migrating away from Heroku if they can avoid it.
Heroku does lots of revenue, even if they pay AWS. I do think it would be worth.. quite a bit. And I would be very happy if a better steward would buy it.
It would be impossible to buy a company as a steward. We worked with them. In the early 2020s, their teams were as lazy as IBM boomers. Happy to hop on a call, but let's do an rain check or whatever and come back to you after 17 weeks to say no in an email CCed with 42 people playing hot potato between commercial people who try their best to sound technical. You need a mind map to know which person you were talking to and who introduced you to them.
My money is on holding companies like IAC buying the brand first through financial engineering and restructuring finances initially. They would load it up with debt like they did with the sporting goods store in Sopranos.
Afterward, they would sell it to a Euro-based caretaking company like Bending Spoons, with a focus on maintenance engineering rather than innovation engineering.
TIL Salesforce acquires Heroku in 2011, way before I was even a CS graduate. I remember enjoying using the free tier of Heroku for my school projects but also the pain of dyno cold starts.
One wonders about the damage caused by putting this vague mess of a post out vs not.
Also feel like many are still trying to recreate the Heroku experience all these years laters tbh
Title should be updated to "Sunsetting Heroku".
I just got some Heroku socks like two months ago at an event, they must've killed it at the start of the year. Weird.
I still haven't used a system as nice as Ruby on Rails and Heroku circa 2014.
> Heroku is transitioning to a sustaining engineering model
sustaining == maintanence mode
What does this even say?
At Google we call it KTLO ("Keep The Lights On")
my heroku app has been crashing since 2 days with the link to amazon rds db. is this part of it ?
Why not use LLMs to maintain Heroku?
it would be too easy to just outright say "we are shutting this down over the next x years, right?
What does this mean in non-corpo speak?
Headline includes the term “update” == always bad news.
They will still raise prices when renewal time comes around.
i am impressed. no ai can ever write announements this bad
So, Andreas killed Heroku, with Coolify?
Just please don't sunset Heroku Connect
Spinning up temporary VMs/stateful machines is going to be super valuable in the next year or 2. Heroku not jumping on this just shows the state of Salesforce. Absolutely inept. I foresee slack going down a similar path of enshittification
Thanks for reminding me that slack is owned by Salesforce. What are we going to use when slack turns to shit, IRC again maybe?
type.com (full disclosure I am one of the cofounders)
You gotta fix the home page. I'm not sitting through a movie trailer to find out how your chat app works.
haha we actually launched it today. Point taken though! It's not a video though just an interactive widget. Instead of scrolling you press enter. Once we launch I'm sure we'll have something more traditional
What are some good alternatives?
Anyone any experience with https://sevalla.com/ ?
I've been very happy with https://render.com/ , seems the closest to what heroku was
Dokku. The self hosted alternative.
Anything that can host Kubetnetes. If you are going to fo devopsy deployments might as well use the standard.
well, this is the only alternative which has exactly the same pipeline
Fly.io is incredible.
garden of ideas now blossoms dancing with wind still creating, still
garden of ideas
now blossoms dancing with wind
still creating, still
chatgpt translation: Heroku isn’t shutting down, but they’re basically done building new stuff. For those who want to move and potentially save $ in process, here is a nice cost comparison: https://infraslash.com/costs/
Was this written by llm?
Dogfooding their future products!
I originally saw this on Twitter/X, the wording here is very confusing. The tl;dr version is simply they are going to be KTLO -keep the lights on- mode.
more like herok-who?
Who cares about heroku in 2026? It’s a dead horse
>> “ we want to be clear about what this means for customers.”
Nope, not clear.
This is a clear message “ the heroku product is cancelled but will not be shut down, will continue to operate exactly as before but no new features will be added.”
Imagine being the Chief Product Officer Since Aug 2025, and in Feb 2026 you are effectively killing your own product.
I mean I know what it means but how can you corpo speak so hard that it's pretty much unclear what the change even is
slopification is the new enshittification
[dead]
[dead]
[flagged]
Why is this so cringe? That's not the typical way AI writing is bad.
Salesforce is the worst, lol
RIP Heroku.
It was good before SalesForce…
In 2018, I had to transition my org at the time from Heroku to AWS (with the org lacking any AWS experience outside of myself).
We ended up with a “Heroku-like” experience. Push to GitHub. Action triggers job. Job packages and deploys. À la carte yaml config for extras like databases and ALBs. It worked pretty well. It was an in house solution to an in house problem.
Still, it wasn’t quite Heroku…