João Freitas

The following is a breakdown on the history of Heroku. The author also describes the monolith to microservices trend, giving examples on how Cloud Providers started to offer platforms for different computing resources.

Today, Heroku is still used by many developers because of its core features: zero-configuration deploy, no need to worry about scaling and developer experience with things like git push heroku to deploy an app.

Heroku made it easy for any developer to build and run applications in the cloud without managing their own infrastructure. Now 15 years later, it continues to inspire the next generation of developers. Why did Heroku become so popular? What can we learn from their incredible developer experience? How is Heroku shaping the next generation of serverless?

Early Days of Heroku

In 2006, Amazon Web Services (AWS) launched EC2, making it easy to run compute on-demand. Developers didn’t need to purchase, set up, and manage their own infrastructure anymore – they could pay for cloud compute as needed.

At the same time, many developers were building monolithic Ruby on Rails applications. Rails made developers incredibly productive at building applications, but it was still painful and time-consuming to get them deployed. Developers might spend weeks (or months) just on deployment.

In 2007, three Ruby developers – James Lindenbaum, Adam Wiggins, and Orion Henry – founded Heroku. Their mission was to make computing more accessible. The first version of Heroku was an in-browser code editor that made it easy to build and deploy Ruby applications.

Heroku's original product, an in-browser IDE allowing you to instantly create and publish Rails apps.

While their original goal was to help educate developers and make computing more accessible, they noticed that many developers weren’t using the platform for learning – they were using it as an easy way to get their Ruby applications deployed. Heroku joined Y Combinator to become the easiest place to build and deploy any Rails application.

Early version of Heroku from 2008, soon after joining Y Combinator.

Shortly after Heroku launched, Google App Engine (2008) and Microsoft Azure (2010) entered the market. A trend started to appear. Developers wanted to spend less time configuring infrastructure, and more time building their application.

In 2010, Heroku was bought by Salesforce for $212 million. At the time of acquisition, Heroku had ~30 employees and only supported Ruby. Y Combinator was still relatively unproven and Heroku was their largest exit yet.

What did Salesforce see in Heroku that led to acquisition?

Early Bets

Heroku made some early tech choices that proved to be very productive for developers building monolithic applications: Ruby on Rails, Git, and Postgres.

Git was created in 2005 by Linus Torvalds to help develop Linux. Even though there were many version control systems at the time, git begun to slowly grow in popularity. However, everything changed when GitHub was founded in 2007.

Like the Heroku founders, the GitHub founders were Ruby developers. In 2008, the Ruby on Rails project switched to using GitHub, and the entire Ruby community followed shortly after (thus adopting git as well). Heroku became synonymous with Rails. Later, the creator of Ruby joined Heroku to continue working on the language.

To run your Rails application, you needed a database. Heroku allowed you to add a Postgres database with one click through add-ons. Today, Postgres has grown to be one of the most popular databases, which wasn’t as obvious in 2008. It became the default choice for folks building monolithic Rails applications.


Adam, the Co-Founder and CTO of Heroku, coined the term 12 factor app. This was the blueprint for building for the web (at the time) and is still relevant many years later.

Developer Productivity

Heroku set a new standard for developer experience. To deploy your application, you pushed code to git and received a URL. git push heroku main. That’s it.

Heroku would build your application remotely (in the cloud) and deploy it to their infrastructure. Developers weren’t used to deployment being this easy or fast. Heroku was ahead of its time and “serverless” in the sense you didn’t have to manage servers yourself.

Heroku's landing page in 2011 after expanding past Ruby to become a cloud application platform

Developers were able to delegate hosting to the Heroku platform without feeling like they were giving up too much control. They didn’t want to manage server maintenance or perform upgrades – but they did want to understand what was happening if things went wrong.


Heroku’s Buildpacks have shaped how software is built today. They automated the build process for any language or framework and transformed the code you write into a deployable image on Heroku. You might hear similar terminology today as “builders” or “adapters”.

As their Co-Founder James said, you “dialed up the knob when you wanted to scale up”. Heroku nailed the CLI experience with commands like:

Heroku's landing page in 2011 after expanding past Ruby to become a cloud application platform

Heroku’s Platform Dominance

Heroku became one of the largest platforms for building and deploying code by providing:

Developers didn’t need to manually configure services to get started. They just pushed code through git. And while Heroku was opinionated about it’s preferred stack (Rails + Postgres), it had a wide ecosystems of add-ons if you had different preferences.

The seamless integration between the framework of choice (Ruby on Rails) and the infrastructure made developers incredibly productive. Developers could deploy a monolithic Rails app to Heroku in a weekend and dial up the knobs as their traffic increased.

Heroku became a focal point of education for anyone working with Rails and Node.js due to its free tier. Hobby developers and students could turn their ideas into production code extremely fast, without needing access to a credit card.

From Monolith to Microservices

During Heroku’s rise to dominance, some developers began to scale out of monolithic workloads. This was expedited by two trends: serverless and Kubernetes.

Serverless and Kurbernetes trends on Google

During this same time period, the types of web experiences developers were trying to build demanded more specialized tools. There was an unbundling of the monolithic into dedicated, specialized services:

Monolith (on a single server)

Microservices (APIs & libraries)


Auth0, AWS Cognito

Database Queries

Prisma, Mongoose


AWS Lambda, Cloud Functions, Azure Functions, Cloudflare Workers

HTML Rendering & Templates

Frontend Frameworks

JavaScript and CSS Bundling

Frontend Frameworks


Firebase, Ably, Pusher, AWS SQS, etc.


AWS S3, Google Cloud Storage

Image Optimization

Imgix, Cloudinary, AWS CloudFront

At the time, monolithic apps were still the fastest way for developers to put an idea into production. This new wave of serverless and Kubernetes was often difficult to use and required specialized talent. Some teams jumped on the new trend too quickly, where it was often cheaper to scale up and pay for a managed platform like Heroku than to hire a team of DevOps engineers.

However, some developers were still ejecting from monolithic platforms due to cost, flexibility, or availability. And the state of tooling for serverless and Kubernetes left a lot to be desired. This lead to a new wave of innovation.

Serverless 1.0

Why did some developers start to explore moving from their monolith to serverless?

For example, let’s say you need to build a backend for a mobile app. Should you use a monolith or serverless? You want it to be scalable, stateless, and available around the world, all without spending too much money or time managing infrastructure.

Bret Taylor, the Co-CEO of Salesforce, co-creator of Google Maps, and former CTO of Facebook, was in this same position in 2019. He built an iOS app to check the air quality and display a widget on his home screen.

He choose AWS Lambda for on-demand compute, AWS S3 for durable storage, and AWS CloudFront to push it to every region.

That’s why I’m exited about serverless: a lot to figure out (debugging, monitoring, local dev), but just like cloud infrastructure made internet scale cheaper and more accessible, serverless has the potential to make internet scale app dev accessible to 10X more developers.

But to “beat” Heroku, you needed to be 10x better. And Serverless 1.0 was not 10x better.

Heroku in 2022

Heroku has had a tough 2022 with multiple security incidents and ongoing outages. This has led some teams who might have skipped the Serverless 1.0 era step back and reevaluate the current state. How are teams building today?

Heroku’s favorite framework – Ruby on Rails – is now hosted on GitHub Pages. None of the 15 Rails companies featured on the home page are using Heroku for their .com (as far as I can tell). Even the biggest Rails shop, GitHub, has started building with React on the frontend and moving the backend to Kubernetes.

What developers loved about Heroku was that they didn’t have to manage infrastructure. Somewhere along the way from monolith to microservices, application developers ended up doing DevOps again. Infrastructure as Code (IaC) tools like Terraform, AWS CDK, and Pulumi enabled a more lean DevOps experience, but still required managing, scaling, and debugging that infrastructure.

Expectations for both frontend and backend experience have risen, making some developers abandon PaaS for a decoupled architecture allowing them to pick the best tools possible.

What can we learn from Heroku?

I’m personally inspired by Heroku and have used the platform since 2012 for some side projects. We can learn a lot from their story and how it’s shaped the software industry.

I’m also biased, as I work at Vercel, in believing serverless and Edge platforms are the future. Here’s my thoughts on where we’re headed:

And that’s all for now. Hopefully you now have a better appreciation how Heroku changed the software industry. If you see anything missing here about the story of Heroku, let me know.

#reads #lee robinson #heroku #monolith #microservices #kubernetes