Heroku recently launched Fir, a major platform rewrite that represents one of the most significant technical undertakings for the company of late. The replatforming effort was aimed at modernizing Heroku’s underpinnings while preserving its core promise: simple deployment and developer-friendly workflows.

But why now? To understand what Fir means and why it matters we have to look back at the road that led us here.

History

or… PaaSt…

(I crack myself up)

The Heroku brand has long been synonymous with simplified developer experience, and in fact arguably invented modern developer experience. With the git push heroku main command, anyone can get an application deployed without having to focus on the underlying infrastructure.

Founded in 2007, Heroku entered the market at roughly the same time Infrastructure-as-a-Service (IaaS) came to being. Amazon introduced EC2 instances in 2006, giving developers access to raw compute but little abstraction. Heroku offered a contrasting vision: instead of provisioning VMs and managing runtimes, users focused on their code and let the platform handle the rest.

It was this user simplicity, combined with building on open standards plus a free tier for hobbyists, that helped Heroku gain traction while previous PaaS solutions like force.com and Google App Engine failed to thrive. For many developers, Heroku wasn’t just a Platform-as-a-Service – it was the Platform-as-a-Service in those halcyon days. It was the place you went to spin up your side project, test out your app idea, or build something useful without having to get permission from your boss first. It became a hugely influential educational application in the Ruby on Rails community, with Michael Hartl pointing learners to this platform in his tutorial.

Heroku was acquired by Salesforce in 2010. While the platform continued to promise simplicity, its strategic direction shifted under new ownership. Meanwhile, the ecosystem around it was growing increasingly complex throughout the 2010’s. Cloud Foundry, a competing open source PaaS solution, entered the landscape, while other PaaS options came and went. Docker, which has begun life as a PaaS company, revolutionized the infrastructure market with its portable, container-based model. New forms of abstraction – primarily containerization, though to some degree also serverless computing – introduced new approaches to architecting applications. All the while, the IaaS category exploded with vendor and service options, offering vast flexibility and choice.

Kubernetes emerged as the decade’s de facto standard, and while many still advocated for the PaaS approach, the PaaS category as a whole struggled to define its role in the shifting landscape.

That said, Heroku played a hugely influential role in defining what ultimately became ‘cloud native,’ at least conceptually if not in implementation detail. The 12-factor app design methodology, git push workflows, buildpacks, environment variables for config, and a focus on apps over infra – all of these practices helped define what we now call ‘cloud native.’ It gave us a model for what developer-friendly platforms and developer-friendly workflows could look like. Heroku might have been playing in a different category, but it arguably invented many of the concepts that underpinned the one that came next.

But in the 2020’s, the pendulum began to swing again. The complexity and fragmentation of the container landscape had become extremely unwieldy, and people were looking for the kind of simplicity Heroku had made look easy. Developers and enterprises alike longed for solutions to the developer experience gap. Adjacent software categories began smooshing together (an officially sanctioned RedMonk term.) Platform Engineering emerged as a potential solution to help enterprises reign in the complexity. New era platforms emerged.

All the while, Heroku continued to operate in the background. But it was not always clear how Salesforce wanted to strategically position Heroku within their own portfolio: was it an independent compute platform for developers or was it an extension of the Salesforce ecosystem? (Hint: the answer in both cases was and remains ‘yes.’)

Add in events like changes to Heroku’s free tier that considerably swayed public opinion, and it was easy for developers outside the ecosystem to feel like Heroku had become a Salesforce tool and not a platform for them.

Today

Heroku today still serves these two audiences, and has been doing considerable work to better serve each constituency.

There’s the Salesforce-aligned audience. There are several reasons developers might want to come to Heroku to extend and enhance the Salesforce ecosystem.

• the developer might want to build in a language other than Apex (a strongly typed language developer by Salesforce for automating and customising functionality on the core Salesforce platform) or JavaScript (Salesforce’s flavour being Lightning Web Components). Heroku may have started out with Rails roots, but it currently supports ten different languages.
• the application might have high compute or high scale processing needs.
• the customer might require real-time data processing for things like fraud detection.

I recently attended TDX (aka Agentforce fka TrailheaDX), Salesforce’s developer-focused event, where they announced features – AppLink and Eventing – that made those use cases much more seamless for the developer. They’re all about simplifying the process of connecting Heroku apps to Salesforce systems and more cleanly enabling event-driven workflows that pass data back and forth. For those in these ecosystem, that’s great progress.

I chatted more about these announcements with Adam Zimman, Heroku’s Head of Product Marketing, if you’d like a deeper dive.

There’s still the classic PaaS offering supporting those who want a clean abstraction layer for running general purpose apps, and there’s also been some exciting movement on Heroku’s core infrastructure. Heroku replatformed itself to Kubernetes; instead of just inspiring cloud native, it is now allowing users to participate in cloud native workflows. What does that mean for users?

Heroku now supports OCI images, which means developers can use cloud native buildpacks to build their app locally and then run it in Docker. They’ve integrated OTel collectors. They’ve increased the number of options for Dyno sizes (Heroku’s basic unit of compute, an app abstraction platform). There’s a clear effort to be part of the modern Cloud Native stack instead of an elegant but lonely island adjacent to it.

Not every workload will be ready to move to Fir. Right now the stack is built entirely on Graviton. While the move to ARM processors is definitely forward looking for Heroku, it also means that x86 workloads will likely not work as-is. The roadmap section marks this as “currently,” indicating that additional processors may be planned in the future. Similarly, they are not currently supporting monorepos. The Fir Platform represents a future-facing move, but there are definite gaps to fill in order for this platform to support the legacy applications already running on Heroku.

Competition

As mentioned above, the industry keeps remaking Heroku. Imitation is the sincerest form of flattery. See modern platforms such as fly.io, Vercel, and Render. Competition in the platform space is much more intense than it was in years past.

Additionally, pricing can remain an objection. Heroku users continues to have the perception that the platform is expensive to run at scale, and that while the platform is great for more limited applications it is not economical for large applications. (Heroku, of course, disagrees with this assessment.)

So What?

So what does this all mean? Importantly, some things haven’t changed. Heroku still wants to abstract away infrastructure. It still focuses on app-centric workflows. You can still connect your app to GitHub and just push to deploy. They’re leaning into extensibility, not complexity.

It means Heroku is trying to rebuild credibility with the devs who once loved it, without abandoning its new mission within the Salesforce universe. It’s a balancing act. But it’s also a chance – maybe – for Heroku to come back from the island and bring some of that original DX magic with it.

---

Disclaimer: Salesforce is a RedMonk client and paid my T&E to TDX; however this post is not commissioned and all opinions are my own. Docker, Google, and GitHub are also clients. Fly.io, Render, and Vercel are not.