Ask a developer who used Heroku what they remember about it and you'll usually get some version of the same answer: you pushed your code and it ran.
That feeling is back in the conversation, mostly because AI tools have made building software faster than its ever been. But speed was only half of the Heroku story. The other half, the part teams ran into a year or two later, matters just as much today. In this post we'll walk through what Heroku got right, where it came up short, and what a platform for engineering teams, operating in the AI era, needs to get right this time around.
What Made Heroku Famous
Heroku launched in 2007 as a place to host Ruby on Rails apps, and it grew into one of the most loved developer platforms of the 2010s. Salesforce acquired it in 2010, and for years it was the default answer to "where should I deploy this?"
The reason was simple. Before Heroku, getting an app into production usually meant provisioning servers, configuring a web server, writing deploy scripts, and hoping the dependencies persisted between environments. Heroku made nearly all of that disappear.
You ran git push, Heroku figured out how to build your app, and scaling up or adding a database took one command. Add a free tier, and it's easy to see why it became the go-to for side projects and startups for so many years.
The real problem Heroku solved was focus. Small teams could ship product without hiring someone to run infrastructure. The platform was opinionated, and for most early-stage apps those opinions were exactly right.
Where Heroku Fell Short: Outgrowing the Platform
The same abstraction that made day one easy tended to make day 500 hard. Heroku was built around a particular shape of application: a stateless web process, a worker or two, and a managed database. As long as your app fit that shape, life was good. Once it didn't, there wasn't much room to work around it.
For some teams it was a customer asking for their data to stay in a specific region. For others it was a service that needed persistent storage, or an endpoint that couldn't finish inside the router's 30-second timeout. Then someone wanted to try a GPU workload. Around the same time the monthly bill usually started creeping up, and the add-ons you'd leaned on for years made moving anywhere else a project of it's own.
The industry also moved. Containers and Kubernetes changed what teams expected from a platform, and Heroku's pace of change slowed. The free tier was retired in November 2022, and on February 6, 2026, Heroku announced a move to a sustaining engineering model, focused on stability, security and support rather than new features. Existing apps keep running, but the direction is pretty clear.
The pattern most teams lived through was the "graduation." A company would start on Heroku, hit one of the walls above, and migrate to raw AWS or a self-managed Kubernetes cluster. They gained flexibility, but they also gained a DevOps backlog, a platform engineering team to staff, and a lot of custom tooling. Neither side of that move was really ideal.
Fast-Forward to Today: Building at AI "Speed"
In 2026, a lot of development happens alongside AI coding agents. A single engineer can describe a service, have an agent scaffold it, write the Dockerfile, wire up a database and draft the deployment config, all in one sitting. With protocols like MCP, agents can now call infrastructure APIs directly, so "deploy this" is increasingly something you ask for rather than something you do by hand.
For a solo developer or a team of two or three, this is close to the original Heroku promise, only faster. You stay focused on the product and the busywork mostly fades away.
Things change once a team grows past a handful of people. Each engineer is now working inside their own chat window or agent session, and the context for what got built and deployed lives in that session. It doesn't live anywhere the rest of the team can see.
This isn't really a failure of the AI tools. The agent knows exactly what it did in its own session. It just has no idea what a teammate's agent did yesterday, and code review only catches what's in the diff, not what changed in the infrastructure around it.
What the Real Answer Looks Like
The fix isn't to slow down development. Rather, it's to give every human and every agent the same place to work from. In practice, that means a DevOps platform where teams can build and deploy with AI, but every change flows through a standardized control plane: one API, one portal, one record of what's running and who changed it.
A few things make that work:
- One source of truth. Agents and engineers use the same API. Whether a deployment came from a terminal, a CI pipeline or an MCP-connected assistant, it shows up in the same place, with the same activity history.
- Visual context for the whole team. A portal where anyone can see environments, services, networks and recent changes, without needing to review somebody else's chat session.
- Agents with the same guardrails as people. Roles and permissions shouldn't change just because a request came from an AI tool.
That last point deserves more than a bullet. Once agents can deploy services, scale them and change configuration, they need to follow the same rules your engineers do, and those rules have to live in the platform rather than in a prompt. Telling an agent "don't touch production" in a chat window is a suggestion. A role that has no access to the production environment is a policy.
In practice this comes down to a handful of things. Agents should authenticate with their own scoped credentials, tied to a real user or a dedicated API key, instead of a shared admin token someone pasted into a config file. Permissions should be scoped the same way they are for people, by environment, action and resource, so an agent helping out in staging simply can't reach production. Secrets should be injected by the platform at runtime so they never need to pass through an agent's context window. And every action, whether it came from someone clicking around the portal or an agent calling the API over MCP, should land in the same audit trail so you can see who (or what) changed something and when.
It's also reasonable to keep a human in the loop for the changes that matter most. Deleting an environment or decommissioning a server is easy to ask for and hard to undo, so those actions can require explicit confirmation or be limited to specific roles. Everyday work can still move quickly. The guardrails just shouldn't depend on how carefully someone worded their prompt.
Then there's the balance Heroku never quite struck. The platform has to be opinionated enough that work stays consistent. Environments, networking, DNS, secrets and deployment patterns should look the same no matter which engineer, or which agent, set them up.
At the same time it has to be customizable enough for real workloads. Most growing teams aren't running one stateless web app. They're running APIs in a few languages, databases, queues, background workers, maybe a legacy service that needs a full virtual machine, and increasingly GPU-heavy AI workloads. They also want a say in where it all runs, whether that's a public cloud, bare metal, or a hybrid infrastructure setup that mixes the two.
The goal is to keep the Heroku feeling of "push and it runs" without the ceiling that eventually pushed teams off the platform.
Where Cycle Fits
This is the problem we've been working on at Cycle, and if your team is weighing a Heroku alternative, it's a good place to start. Cycle is a platform for running containers and virtual machines on infrastructure you choose, across public cloud providers and bare metal, managed through a single API and portal. The Cycle team handles the platform itself, including updates to the underlying OS and orchestration layer, so your engineers aren't maintaining a cluster on the side.
Cycle is opinionated where it helps. Environments, private networking, load balancing, DNS and scoped variables all work the same way for every service, so one team's setup is easy for another team to read. It's flexible where it needs to be: any language, stateful workloads, VMs next to containers, and multiple providers in the same hub. If you're curious why we think teams shouldn't have to pick between too simple and too complex, our manifesto goes into more detail.
For teams wanting to build with AI, Cycle also offers a hosted MCP server, so tools like Claude can deploy services, read logs and help diagnose issues directly. Those actions go through the same API the portal uses. When an agent deploys something, the rest of the team can see it, in the same place they'd see a deploy from a teammate or a pipeline. Because it's the same API, the same access rules apply too: API keys and hub roles are scoped by capability, so an agent can only do what the credentials it's using allow.
If your team is moving faster than ever with AI but starting to lose track of what's running where, we'd be happy to show you how Cycle works. You can create a hub and try it on your own infrastructure, or reach out to the Cycle team and we'll walk through it with you.