Heroku
The platform that defined PaaS: git push your code, and Heroku builds it with a buildpack and runs it on managed containers called dynos behind its own HTTP router.
- What it is
- Platform as a service (PaaS)
- Type
- Commercial product
- Made by
- Salesforce, Inc.
- License
- Proprietary (its buildpacks are open source)
- Facts checked
- 12 October 2026
What it is
You push code to a Git remote named heroku. A buildpack detects the language from files such as package.json or requirements.txt, fetches dependencies and compiles the app into a build artifact: a slug (a tarball with the code and its runtime) on the older Cedar generation, an OCI image built by Cloud Native Buildpacks on the newer Fir generation. Heroku pairs the artifact with your config vars and add-ons into a numbered release, kept in an append-only ledger, so heroku releases:rollback starts an older one again. The dyno manager then runs each line of your Procfile (web, worker and so on) on dynos, isolated Linux containers, as many as you scale each process type to. Only web dynos get HTTP traffic: Heroku’s routers pick one at random for each request. Dynos are replaced on every deploy and cycled automatically (at least once a day unless configured otherwise), each with a fresh, ephemeral filesystem, so state lives in add-ons such as Heroku Postgres, whose credentials arrive as environment variables like DATABASE_URL.
Prices are per dyno. On the Common Runtime, Eco costs $5 a month for a pool of 1,000 dyno hours shared by all Eco dynos, which sleep after 30 minutes without traffic; Basic is $7 with 0.5 GB and one dyno per process type; Standard-1X (0.5 GB) and Standard-2X (1 GB) cost $25 and $50; single-tenant Performance dynos run from $250 (2.5 GB) to $1,500 (126 GB) and support autoscaling. Fir, rolled out from 2025 and generally available with Fir Private Spaces, runs dynos on Kubernetes on AWS (EKS), uses Cloud Native Buildpacks by default, offers x86 and ARM dynos and exports telemetry with OpenTelemetry.
Heroku is part of Salesforce. On February 6, 2026, it moved to a “sustaining engineering model” focused on stability, security, reliability and support rather than new features, and stopped offering Enterprise Account contracts to new customers; credit-card customers saw no change, and smaller releases, such as Heroku Postgres Advanced in October 2026, continue.
Why teams pick it
- The whole deploy path is
git push, with official buildpacks for Ruby, Node.js, Java, Python, Clojure, Scala, Go, PHP and .NET - Every change to code, config vars or add-ons is a numbered release, and rolling back is one command
- The Elements Marketplace attaches databases, caches, logging and more as add-ons that hand the app their credentials in config vars
- Fir builds standard OCI images with Cloud Native Buildpacks, and Heroku’s builder also runs locally with the
packCLI
Watch out for
- The router ends any request that takes longer than 30 seconds, and the limit can’t be changed: long work has to go to a worker dyno
- Files written to a dyno vanish when it restarts, which happens on every deploy and on the regular, automatic dyno cycling
- Eco and Basic dynos can’t scale out, and Eco dynos sleep after 30 minutes idle and take a few seconds to wake
- Since February 2026 Heroku is in sustaining engineering: new Enterprise contracts are no longer sold, and the stated focus is stability over new features
Alternatives
What all platform as a service (paas) have in common →
AWS Elastic BeanstalkAWSUpload your code and Elastic Beanstalk builds the AWS setup to run it (EC2 instances, a load balancer, an Auto Scaling group) in your own account, where you can still see and change every piece.
Azure App ServiceAzureAzure’s platform for web apps and APIs: you rent a pool of VMs called an App Service plan, and every app you put in it runs on those VMs without you managing them.
Cloud FoundryOpen sourceAn open-source PaaS you run yourself: `cf push` uploads your code, a buildpack stages it into a droplet, and Diego keeps the requested number of instances running behind the Gorouter.
DokkuOpen sourceA Heroku-like PaaS on one server of your own: `git push` to it, and Dokku builds the app with buildpacks or a Dockerfile and runs it in Docker containers behind nginx.
Fly.ioCommercialFly.io turns your Docker image into fast-booting Firecracker microVMs on its own servers in regions around the world, and routes each user to the nearest one.
Google App EngineGoogle CloudGoogle’s original platform as a service: describe your app in an `app.yaml`, run one deploy command, and Google runs and scales the instances.
RenderCommercialRender builds and deploys web services, background workers, cron jobs and managed Postgres and Key Value stores from your Git repo, all described in one `render.yaml` file if you like.How it fits with other technologies
Create, deploy, scale and roll back an app with the Heroku CLI · bash
heroku create -a example-app # empty app plus a Git remote named heroku
git push heroku main # buildpack build, new release, one web dyno
heroku ps:scale web=3 queue=2 # dyno formation per Procfile process type
heroku config:set ENCRYPTION_KEY=secret # config var, exposed as an env var; new release
heroku addons:create heroku-redis:mini # Key-Value Store add-on; sets REDIS_URL
heroku logs --ps web.1 --tail # one dyno's log stream from Logplex
heroku releases:rollback v102 # run an earlier release againSee it in a real stack
No architecture uses Heroku yet. Drop it into the playground and wire it up yourself.Open playground →Where it came from2007–2026
Heroku began in June 2007, built by James Lindenbaum, Adam Wiggins and Orion Henry to run Ruby apps written for Rack. Heroku’s pitch, as Salesforce later put it, was “no virtual machines to manage, no software to install, and no hardware to manage and tune”: push the code and the platform does the rest. A rebuilt platform launched in January 2009.
Salesforce agreed to buy Heroku on December 8, 2010, for about $212 million, when it ran more than 105,000 apps. Heroku grew from Ruby into a polyglot platform: in 2011 it conceived buildpacks, open scripts that teach the build system a new language, and Wiggins wrote the twelve-factor app from what the team had seen across hundreds of thousands of apps. In 2018 Heroku and Pivotal started Cloud Native Buildpacks to make the idea a standard that outputs OCI images.
Heroku’s free dyno and data plans ended from November 28, 2022, with Heroku citing the effort spent on fraud and abuse. From 2025, Heroku rebuilt the platform as Fir, on Kubernetes, OCI images and OpenTelemetry. In February 2026 it moved to a sustaining engineering model, concentrating on keeping existing customers’ apps stable and secure.
Why it’s built this way
git pushas the deploy interface- Developers already used Git, so Heroku made deploying “the familiar
git push”, to a remote it adds when you create the app. GitHub integration and the Platform API are other ways to send it. - A Procfile of named process types
- Declaring
webandqueueas separate commands exposes the app’s architecture to the platform, so each part can be scaled on its own, and onlywebdynos get routed traffic. - Releases as an append-only ledger
- A release binds a build to config vars and add-ons. Changing any of them makes a new release instead of editing the running one, which gives an audit trail and makes rollback a matter of starting an old release.
- Open standards for Fir
- Heroku says Fir uses Kubernetes, OCI containers and OpenTelemetry to “future-proof” apps and fit modern cloud tooling, while keeping the Heroku workflow on top.
Timeline
- 2007
Development starts in June, for Ruby apps only
- 2010
Salesforce agrees to buy Heroku for about $212 million on December 8
- 2011
Heroku conceives buildpacks; Adam Wiggins writes the twelve-factor app
- 2018
Heroku and Pivotal start Cloud Native Buildpacks
- 2022
Free dynos and data plans end from November 28
- 2025
Fir, the Kubernetes-based generation, begins rolling out
- 2026
Heroku moves to a sustaining engineering model on February 6
- Wikipedia: Heroku (founders, June 2007, 2009 platform)
- Salesforce: Salesforce.com Signs Definitive Agreement to Acquire Heroku (Dec 8, 2010)
- Cloud Native Buildpacks: History (buildpacks conceived by Heroku in 2011; CNB in 2018)
- Heroku blog: Heroku Open Sources the Twelve-Factor App Definition (Nov 12, 2024)
- The Twelve-Factor App: Background
- Heroku blog: Heroku’s Next Chapter (Aug 25, 2022)
- Heroku Dev Center: Heroku Generations (Cedar and Fir)
- Heroku Dev Center: How Heroku Works (Git, Procfile, releases)
- Heroku blog: An Update on Heroku (Feb 6, 2026)
Sources13 · facts checked 12 October 2026
- Heroku Dev Center: How Heroku Works
- Heroku Dev Center: Dynos (cycling, ephemeral filesystem, scaling)
- Heroku Dev Center: Dyno Types (Cedar and Fir sizes and prices)
- Heroku Dev Center: Dyno Tiers (Eco hours, Basic limits, Performance autoscaling)
- Heroku Dev Center: HTTP Routing (random dyno selection)
- Heroku Dev Center: Request Timeout (30 seconds)
- Heroku Dev Center: Buildpacks (classic and Cloud Native, supported languages)
- Heroku Dev Center: Heroku Generations (Fir on Kubernetes and EKS, OpenTelemetry)
- Heroku Dev Center: Add-ons (Elements Marketplace)
- Heroku Dev Center: Deploying with Git (heroku create)
- Heroku blog: An Update on Heroku (Feb 6, 2026)
- Heroku blog: Heroku March 2026 Update (1 GB slugs, CLI v11)
- Heroku blog: October 2026 Update (Heroku Postgres Advanced, Postgres 18 default)