What Is Heroku? History, How It Works, and What Sustain Mode Means in 2026

Heroku is the platform that invented modern PaaS. Push code, get a URL. It shaped how a generation of developers thinks about deployment. In February 2026, Salesforce moved Heroku to sustain mode — security patches only, no new features. Here's what Heroku is, how it works, and what the sustain mode decision means for developers still on the platform.

#What Heroku is

Heroku is a Platform as a Service (PaaS) that lets developers deploy, manage, and scale applications without managing servers. You push your code. Heroku builds it, runs it, and gives you a URL. No SSH, no server configuration, no infrastructure management.

The concept sounds obvious now. In 2007, it wasn't. Heroku introduced the idea that deployment could be a single command — git push heroku main — and that developers shouldn't need to think about the machines their code runs on. Every modern PaaS, from Railway to Render to Fly.io, traces its DNA back to this model.

Heroku runs applications inside dynos — lightweight Linux containers managed by the platform. You configure your app with a Procfile, Heroku detects your language via buildpacks, and the platform handles the rest: process management, routing, TLS, logging, and scaling. An add-ons marketplace with 200+ integrations provides managed databases, caching, monitoring, email delivery, and more.

For a broader view of where Heroku fits in the cloud computing stack, see our IaaS vs PaaS vs SaaS explainer.

#How Heroku works

The deployment model is straightforward. You write code, define a Procfile, and push to Heroku's Git remote. The platform does everything else.

The Procfile

A Procfile tells Heroku what processes to run. It's a plain text file in your project root:

web: gunicorn myapp.wsgi
worker: celery -A myapp worker
clock: python clock.py

Each line defines a process type and the command to execute it. web processes receive HTTP traffic. Everything else runs as background workers.

Buildpacks

When you push code, Heroku runs it through a buildpack — a set of scripts that detect your language, install dependencies, and compile your application into a slug (a compressed, ready-to-execute bundle). Heroku provides official buildpacks for Ruby, Node.js, Python, Java, PHP, Go, Scala, and Clojure. Third-party buildpacks extend support to nearly any language.

The buildpack system separated "how to build" from "how to run." One set of scripts handles Python dependency installation; a completely different set handles Java compilation. Developers never touch Dockerfiles or build pipelines — the buildpack does it.

Dynos

A dyno is Heroku's unit of compute — an isolated Linux container running one of your process types. Dynos come in several tiers from Eco ($5/month shared) to Performance-2XL ($1,500/month dedicated). You scale by adding more dynos of a process type, and Heroku's router distributes traffic across them.

The deploy flow

The sequence looks like this:

• You run git push heroku main
• Heroku receives the push and detects the language via buildpack
• The buildpack installs dependencies and compiles a slug
• The slug is distributed to one or more dynos
• Heroku's HTTP router sends traffic to your web dynos
• Logs stream to heroku logs --tail

The entire cycle from push to live URL typically takes 30-90 seconds. No infrastructure decisions anywhere in the process.

Add-ons

Heroku's add-ons marketplace provides managed services that attach to your app via environment variables. Heroku Postgres is the most popular — a fully managed PostgreSQL database with automated backups, point-in-time recovery, and follower databases. Other categories include Redis (Heroku Data for Redis), monitoring (New Relic, Datadog), email (SendGrid, Mailgun), search (Elasticsearch), and dozens more.

#A brief history of Heroku

2007: The beginning

James Lindenbaum, Adam Wiggins, and Orion Henry founded Heroku in June 2007. The original product was an in-browser code editor for building and deploying Ruby applications — a radical idea at a time when deployment meant SSH-ing into servers and running scripts manually. The name "Heroku" is a portmanteau of "heroic" and "haiku," reflecting the founders' appreciation for elegant simplicity.

Heroku went through Y Combinator in the Winter 2008 batch. By 2009, the platform had shifted from the browser-based editor to the Git-based deployment model that would become its defining feature.

2010: Cedar and the polyglot pivot

The Cedar stack, introduced in 2010 and made the default in 2011, transformed Heroku from a Ruby-only platform into a polyglot system supporting Ruby, Node.js, Python, Java, Scala, and Clojure. This was made possible by the buildpack architecture — a composable build system where language-specific logic is modular and extensible.

Cedar also introduced the process model (Procfile), one-off dynos (heroku run), and the HTTP routing changes that defined Heroku's architecture for the next decade. Around this time, Adam Wiggins published The Twelve-Factor App — a methodology for building cloud-native applications that became an industry standard far beyond Heroku.

By mid-2010, over 100,000 applications were running on the platform.

2010-2011: The Salesforce acquisition

In December 2010, Salesforce announced it was acquiring Heroku for $212 million in cash. The deal closed in January 2011. Heroku had raised only $13 million in funding at that point, making it a substantial exit. Salesforce saw Heroku as a way to court the next generation of developers building social and mobile applications.

For several years after the acquisition, Heroku operated with real autonomy. The add-ons marketplace expanded, and "just deploy it to Heroku" remained the standard advice in every web framework tutorial.

2015-2019: The slow plateau

The pace of major features slowed. Competitors emerged. AWS launched Elastic Beanstalk and then ECS. Google introduced App Engine and Cloud Run. Docker changed how developers thought about packaging applications. Kubernetes became the industry standard for container orchestration.

Heroku remained popular — particularly for prototypes, side projects, and teams that valued simplicity over flexibility. But the platform increasingly felt like it was coasting. Pricing didn't change. The routing layer had known limitations. The dashboard looked the same year after year.

2022: The GitHub security incident and free tier removal

In April 2022, attackers compromised Heroku's OAuth tokens for GitHub integrations. The breach forced Heroku to revoke all GitHub OAuth tokens, breaking the GitHub deployment integration for weeks. It was a significant trust event for a platform whose core value proposition was reliability and simplicity.

Seven months later, in November 2022, Heroku removed its free tier entirely. Free dynos, free Postgres, free Redis — all gone. The free tier had been Heroku's most powerful growth engine. Every Rails tutorial, every Django quickstart, every university course that said "deploy to Heroku for free" needed to find a new recommendation. The migration to Railway, Render, and Fly.io accelerated dramatically.

2024-2025: The Fir generation

Heroku launched Fir, its next-generation platform built on Kubernetes. Fir brought significant technical upgrades: Kubernetes-backed Private Spaces, ARM-based Graviton dynos, Cloud Native Buildpacks replacing the legacy buildpack format, and IPv6 networking. Heroku also shipped Heroku AI for managed inference, a next-generation Postgres Advanced tier, and GitHub Enterprise Server integration (which reached GA on February 11, 2026).

February 2026: Sustain mode

On February 6, 2026, Nitin Bhat — Heroku's Chief Product Officer — announced that Heroku was transitioning to a "sustaining engineering model." Every new feature that had just shipped — Fir, Heroku AI, Postgres Advanced — was effectively frozen. The full implications are covered in the section below.

#Heroku pricing in 2026

Heroku uses a per-dyno monthly pricing model. There is no free tier (as of March 2026). Here are the current dyno types:

Database, Redis, and other add-on costs are separate. A typical startup workload — two web dynos, a worker, and managed Postgres — runs $100-300/month.

The Common Runtime is available in US and EU regions only. Private Spaces (Fir or Cedar) support 10 regions.

For context on how this compares to modern alternatives: Railway starts at $5/month with usage-based billing. Render offers a free tier for static sites and starts at $7/month for web services. AZIN deploys to your own GCP account where GKE Autopilot's first cluster is free — you pay only for the resources your workloads consume. See our best Heroku alternatives guide for a full breakdown.

#What sustain mode means

On February 6, 2026, Heroku's CPO Nitin Bhat announced that Salesforce is transitioning Heroku to a "sustaining engineering model focused on stability, security, reliability, and support." Here is what that means in practice.

What continues:

• Security patches, reliability updates, and stability fixes
• Customer support for existing users
• Credit-card customers (both existing and new) can continue using Heroku with no changes to pricing, billing, or service
• Existing Enterprise Account subscribers can renew their contracts

What stops:

• No new feature development
• No new Enterprise Account contracts for new customers
• The Fir generation, Heroku AI, and all recently shipped features are functionally frozen — they'll receive maintenance updates but no further development

What it signals: Salesforce is concentrating engineering resources on AI-focused products. Industry analysts at The Register, InfoWorld, DevOps.com, and others interpreted the announcement as preparation for an eventual phase-out of Heroku, though Salesforce has not stated this explicitly. The official position is that Heroku remains "an actively supported, production-ready platform."

This is not an immediate shutdown. Heroku is not going offline. But the trajectory is clear: a platform that receives no new features falls behind while competitors ship improvements.

#Should you still use Heroku?

Existing apps that work fine. If your application runs on Heroku today without issues, there is no immediate urgency to migrate. Security patches will continue. Your bill won't change. The platform isn't shutting down tomorrow. But you should start evaluating alternatives before your next major infrastructure decision — adding a new service, scaling up, or renewing an Enterprise contract.

New projects. Better options exist. Railway, Render, and Fly.io offer the same git push simplicity with active development, modern pricing models, and features Heroku will never ship. If you want infrastructure ownership, BYOC platforms deploy to your own cloud account.

Enterprise customers. If your contract is up for renewal, this is the moment to evaluate alternatives seriously. New Enterprise Account contracts are no longer available, which limits Heroku's ability to negotiate or offer customized terms. Your leverage decreases with each renewal as Salesforce reduces its investment in the platform.

Startups and teams with cloud credits. Heroku cannot use your AWS, GCP, or Azure credits — everything runs on Heroku's own infrastructure. If you have credits from Google for Startups, AWS Activate, or similar programs, a BYOC platform lets you apply them directly to your infrastructure costs.

#Alternatives to Heroku in 2026

The PaaS landscape has changed since Heroku's peak.

Modern shared PaaS. Railway and Render are the closest spiritual successors — git-push deployment, managed databases, and developer-friendly pricing. Railway offers usage-based billing. Render offers a free tier for static sites. Both are actively developed.

Edge and distributed compute. Fly.io runs containers on edge infrastructure in 18 regions. Best for latency-sensitive applications that need to run close to users.

BYOC platforms. AZIN, Porter, and Flightcontrol deploy to your own cloud account. You keep infrastructure ownership, use your cloud credits, and maintain compliance control. Our AZIN vs Heroku comparison breaks down the differences in detail.

Self-hosted. Coolify and Kamal are open-source options for teams that want to run their own deployment platform on their own servers.

For the full comparison with pricing, features, and recommendations, read our best Heroku alternatives in 2026 guide.

#Migrating from Heroku

If you've decided to move, the migration process follows a standard pattern regardless of destination:

• Export your data — pg_dump for Postgres, export environment variables via heroku config
• Choose a destination — shared PaaS for simplicity, BYOC for ownership
• Deploy your application — most modern platforms support the same git push workflow or GitHub integration
• Migrate your database — dump and restore, or use replication for zero-downtime cutover
• Switch DNS — point your domain to the new platform after verification

The application code itself rarely needs changes. The Procfile format is widely supported, and environment variables translate directly. The main gotcha is Heroku-specific add-on URLs — if your code references HEROKU_POSTGRESQL_* or add-on-provisioned connection strings, you'll need to update those to match whatever your new platform provides.

For a step-by-step walkthrough with code examples, see our Heroku migration guide.

#AZIN as a migration path

AZIN deploys to your own Google Cloud account via GKE Autopilot rather than shared infrastructure. The workflow is familiar — push code, get a URL — but the build runs through Railpack (a zero-config builder), and the resulting containers land in a GKE cluster you own. Networking, TLS, and autoscaling are managed for you. You pay Google directly for compute.

GKE Autopilot's first cluster is free, and Google for Startups credits apply directly. For Heroku teams with cloud credits sitting unused, that alone can shift the cost equation.

The bigger point for teams watching the sustain mode situation: your infrastructure lives in your own cloud account. No third party decides when it stops getting updates.