We’ve been pretty hesitant to write something of this sort for fear that it looked like we were dancing on the grave of a competitor. However, that isn’t the really the set of emotions that we were feeling here at Railway.

Mourning is the right word for it.

I feel like that is the appropriate feeling to have when a beloved experience that was core to your upbringing as a developer is essentially going to be going away for good.

This is a bit of an awkward topic to bring up on a company blog because we get asked a lot about competition. Specifically, we get asked who are Railway’s competitors are. …and it’s a weird question to answer. Because of course, we’re ambitious, we want to be as big as possible for the sake of our customers. So we get squeamish when people fairly assume when they bring up another neo-cloud as what they assume that’s our primary targets to be- but that’s not how we see it.

Yes, we are fighting for the same set of customers, but the target we have is squarely developer toil.

Employees at the Public Clouds that we frankly do sometimes poke at are the same set of individuals who have to carry a pager getting woken up at 3 AM- our goal is to make it so that no one any longer has to ruin a good night of sleep to keep a server happy. So for a product that meant so much for all of us to effectively be gone, it is not a moment we rejoice in.

After Amazon Web Services began to offer compute via it’s portfolio of foundational products such as Simple Queue Service in 2004, Simple Storage Service (S3) in 2006, and Elastic Compute Cloud (EC2) in 2006 - AWS and the broader cloud market finally began the move to the cloud as part of the shift of the server market moving to commodity linux machines kicking off the better part of 20 years of modern infrastructure development.

In parallel, the Ruby community was emerging after the adoption of Ruby for multiple web software products that grown in popularity. Self taught software developers started reaching for Ruby because of superior developer ergonomics over other runtimes at the time. After David Heinemeier Hansson launched Rails to the broader public in 2004, a new wave of web developers found that they could get more done with Rails than any other web framework in that era.

It is from these two foundational pillars that Orion Henry, James Lindenbaum, and Adam Wiggins, built and launched the first version of Heroku in 2007. Initially developed as a online REPL, they found that users were using the product to deliver production applications as Rails developers found that it was the easiest platform to get their applications online. Alongside the evangelization of The Twelve Factor App that led a lot of modern developers to have a good framework of how to deliver and deploy web applications, Heroku gathered mindshare.

However, the deep magic that Heroku provided was, in my mind, git push heroku master - from the terminal, provided you had a Rails app, you could get an application that just worked with a URL by default. It is an absolutely magical experience.

Heroku went on to co-develop the UI for dynos (their terminology for a running workload) and the CLI at the same time. They then shipped logs, plugins (DBs), and horizontal scaling. At one point, Heroku did count on Facebook (Meta) and a customer.

Those who want to do a deep dive on an oral history from one of the co-founders themselves, as well as their general philosophy Adam Wiggins has a wonderful interview on refactoring.fm.

While everyone points to 2022 and some impacts to service quality as the death of the platform. There was a few junctions at the beginning of the product that served as a damper to their growth.

On one hand, the cloud ecosystem was still nascent around 2009, with nearly every company having to go off and figure out challenges like continuous integration, continuous delivery, repo storage, collaboration, builds, network scaling- much of what we take for granted in the ecosystem today had to be hardened and then delivered. When selling to larger and established organizations, the deluge of requirements for each team meant that many of those companies opted for developer consultants to build on AWS or kept their in-house servers and asked the Heroku team to build on top of it.

From an InfoWorld article, founding engineer Blake Mizerany had this to say about the early motion with developers around that time:

“I think we were possibly too early in wanting everything to be simple, which becomes difficult when you turn around and try to go to the Java community, with its immense amount of tooling and deeply embedded ways of working,”

“That would bite us a little bit when we spoke to companies that wanted to build on Heroku, because they always needed something way off the happy path with Heroku.”

In 2010, the Heroku team had an admirer in the form of co-founder and Salesforce CTO Parker Harris - at the time, Salesforce was working on extending the functionality of the Salesforce Application Platform and was looking to get in the cloud game and Heroku offered to be a good fit. On January 31st, 2011 - Heroku officially was wholly owned by Salesforce.

The team would be relatively undisrupted well into 2018 where they faced other challenges in the cloud market.

On one hand, Rails, although popular (and has an insane market cap of companies) started to be supplanted by Node as the language of choice for a lot of web developers- so non-Ruby experiences started to lose a bit of the magic that the out of the box Heroku experience offered.

On the other, the rise of Developer Operations, or Dev Ops as a unique title where companies who were large enough were standing up entire teams focused on developer productivity and were delivering at scale on the web led to an entirely different set of tools that started on the Linux side of the house, where in they were compromised in terms of UX but weren’t short of power. That led to a rise of tools like OpenStack, CoreOS, and Kubernetes. Where these weren’t competitors the way a PaaS was, but when faced with an internal operations team, many companies felt that it was okay to scale further than the Heroku platform than they could.

However, one product decision Heroku made led to the irrelevance of the platform.

While companies were staffing up their infra teams, the Ruby developers were right about a core instinct that Rails offered. The Rails development experience was largely the same on your laptop as it was in the cloud. You could connect to your running instance, run rake tools, and be on your way. However, for many organizations, a desire for immutability was growing as config and state drift became larger and larger issues at larger companies.

In March 2013, Solomon Hykes demoed a tool called Docker at PyCon. In under five minutes, he showed a room of developers something that would reshape the entire infrastructure industry: a portable, reproducible container that could run anywhere.
This was, on its surface, solving the same fundamental problem that Heroku's buildpacks had solved years earlier, "it works on my machine" was becoming "it works in this container." But there was a critical difference. Buildpacks were Heroku's proprietary magic. Containers were an open standard that belonged to everyone.

For a moment, this didn't matter.

Heroku was still the best experience for getting an app online, but there was a real window probably two to three years where Heroku could have said: "Bring us your Dockerfile. We'll run it with the same DX you already love." They could have been the friendly frontend to the container revolution.

Instead, buoyed from the success of Heroku Postgres the Heroku team was on an engineering death march building the Heroku Marketplace. By it’s release, the market was moving on and large multimillion dollar companies spun up to focus on solving one part of the cloud journey like DataDog, CircleCI, and numerous platform companies like Rancher and CoreOS.

In parallel, Heroku ran on AWS.

Every dyno a customer spun up, every Postgres database they provisioned, every byte of bandwidth they consumed underneath it all, Salesforce was paying Amazon. This meant that Heroku's business was structurally a margin layer on top of someone else's infrastructure. The better Heroku did, the better AWS did. But the reverse wasn't true.

Your cost floor is set by your provider, your ceiling is set by what customers will pay, and the spread between the two is your entire business. As AWS's own products matured as they shipped Elastic Beanstalk, App Runner, and eventually made ECS and EKS more accessible that ceiling started compressing. Customers who were price-sensitive enough to care about the markup could increasingly go straight to the source.

As Docker matured, then Kubernetes emerged as the orchestration layer over Twitter’s Mesos, and suddenly enterprises had a story for running containers at scale that while brutally complex was open, portable, and not locked to any one vendor. Terraform gave teams a way to define that infrastructure declaratively across clouds. The ecosystem was building a stack, layer by layer, and Heroku was on the outside of it.

The developers who had grown up on Heroku's magic were now senior engineers and engineering managers making platform decisions. They loved what Heroku had given them early in their careers, but when they looked at deploying their company's services, they couldn't justify a platform that didn't speak the language the rest of the industry had adopted. So they left not because Heroku got worse, but because it refused to meet the world where it had moved to.

That said, in moving towards that world - developers were taken too far from the magical simplicity that Heroku once offered. At least, that’s what we believe to be our reason to exist, to remove the chaos from production and paradoxically offer the simplest yet most powerful platform for you to use.

If you will forgive the plug for our company here, we feel that Railway most embodies the relentless focus on developer experience that Heroku once did. The whole company is staffed with people who obsess with getting code to run as easily and as cost effectively as powerful. We push our systems to the limit, so that our customers can benefit from the innovation we muster at every layer of the stack.

Done right, Infra should disappear.

We'll admit it! Railway was copying our homework from Heroku when we initially shipped railway up. That command exists because git push heroku master changed what we thought was possible. The difference is that Railway runs on containers and open standards, so the magic never becomes a wall.

One-click Postgres, MySQL, Redis, MongoDB - because Heroku was right that databases belong on the platform. One-click scaling with usage based pricing; because the experience shouldn't be expensive when you scale. And SSH into any running service because when you need to reach into your own application, you should be able to.

Heroku taught us that the gap between writing code and running it could nearly disappear. We're trying to honor that by making sure it never has to come at the cost of control.

The reflexive lesson people draw from Heroku's story is "never sell your company."

We don't think that's quite right.

The Salesforce acquisition accelerated Heroku's decline, but Heroku was already facing headwinds that selling didn't cause. Rails was losing its monopoly on web development mindshare. The DevOps movement was pulling enterprises toward more configurable (if uglier) tooling. The cloud ecosystem that barely existed when Heroku launched had matured into a sprawling landscape of specialized services.

We knew that for Railway to be a trusted platform, we needed to be opinionated enough to guide developers to production on the express line. However, provide off-ramps so that a developer can choose their own adventure on the platform if they needed to customize the experience for their application.

From Day 1, we had this notion at the forefront.

The other notion that we have intuited is that you can’t build a cloud on another cloud. We have devoted years of practice running our own metal (and playing well with other clouds) to make sure that Railway’s business, which invariably becomes your customer’s business, is as rock solid as possible.

We think about all of this, and other business stories a lot at Railway.

Not because we have some masterful strategic insight that Heroku's team lacked. They were, and many still are, some of the best product minds in infrastructure. We think about it because these are cautionary tales that apply to us too. The moment we start fighting the standards our developers have adopted rather than making those standards feel magical or the moment we stop earning our margin through a genuinely better experience we've started down the same path, then you can write a post exactly like this one.

If you are looking for a home for your applications, hopefully Railway can be one for your company. You can try it now at https://dev.new