
Enabling developers to build and run applications in the cloud.
Explore the risks and possibilities with a prompt for ChatGPT, Claude, or your agent.
Heroku became part of Salesforce in 2011 and continues to operate as an application platform. James Lindenbaum, Adam Wiggins, and Orion Henry founded it in July 2007 and entered Y Combinator's Winter 2008 batch. The company turned application deployment from infrastructure work into a developer workflow, reached more than 105,000 hosted applications, and signed a merger agreement with Salesforce in December 2010. The acquisition closed January 3, 2011.[3][8][1][2]

Heroku survived for more than fifteen years after closing, evolving from Ruby hosting into a polyglot platform with dynos, add-ons, managed Postgres, buildpacks, and multiple platform generations. Its February 2026 sustaining-engineering announcement narrowed new Enterprise contracting while preserving existing service. March and September releases show that product changes continued.[5][21][22]
The founders first addressed two barriers to using Rails: installing development tools and publishing small applications. Wiggins' October 2007 announcement described a hosted development environment, not yet the mature deployment platform.[27]
Customer use changed that design. By January 2009, Lindenbaum reported more than 20,000 applications in the first platform and a separate commercial version built for production. The original web-based editor would move to Heroku Garden. That split matters: beginner convenience and production operations needed different products.[28] Heroku commercially launched in April 2009 around Ruby.[1]
The deployment workflow became the product. Instead of asking developers to become infrastructure operators, Heroku presented an application abstraction and handled the runtime beneath it. Early deployment became closely associated with pushing code through a Git-like flow, while the platform supplied process execution, routing, logs, data services, and scaling.[13] In October 2009, CEO Byron Sebastian reported business arriving through consultancies that recommended Heroku to their clients. Partners could distribute the platform as part of their own application work.[34]
By May 2010, Heroku reported more than 60,000 applications and a $10 million Series B led by Ignition Partners. It planned to fund platform development, partner programs, and go-to-market work.[29] TechCrunch listed investors Redpoint, Baseline, Harrison Metal; customers Shopify, Comcast; and total funding above $13 million.[6] Add-ons gave service providers a distribution channel inside that workflow. An April 2010 roadmap already described the add-on system; Heroku's retrospective history dates its introduction to September 2010 and the PostgreSQL add-on to November. The exact launch milestone is inconsistent across those accounts.[1][31]
Heroku's core abstraction was the application rather than the machine. Current documentation still describes dynos as isolated virtualized Unix containers with ephemeral filesystems. Git, GitHub, or API input becomes a build artifact; a release combines that artifact with configuration and attached services; dynos execute declared processes.[13]
Cedar formalized the process model in May 2011. A Procfile defined web, worker, scheduled, and other process types. Teams could scale each type independently, pay by dyno-hour, stream consolidated logs, and start one-off attached processes with heroku run. Its HTTP stack added HTTP/1.1, long polling, chunked responses, and asynchronous multi-connection server support.

Heroku had begun pursuing a language-neutral substrate in early 2010 rather than building separate platforms for each language.[14] By June 2012 Cedar officially supported Clojure, Java, Node.js, Python, Ruby, and Scala. More than 80,000 developers had deployed over 4.5 million times, and Cedar represented more than 75 percent of development activity.[15]

Buildpacks were the adapter layer. They separated language detection and compilation from the language-agnostic runtime, and could be customized and shared for additional languages and binaries.[16] Heroku later contributed Cloud Native Buildpacks to the CNCF, according to its 2022 announcement.[11] The related Twelve-Factor methodology codified operational principles including explicit dependencies, environment configuration, backing services, build-release-run separation, stateless processes, disposability, logs as streams, and dev-production parity.[17]

The add-on model made databases, queues, caches, storage, email, and other services attachable resources supplied by Heroku or third parties. Heroku Postgres became a standalone product in November 2011.[1] That ecosystem expanded developers' options while also creating an inventory of external dependencies behind a deliberately simple interface.
The platform continues to expose Cedar dynos and a Kubernetes-powered Fir generation. Fir uses OCI images, Cloud Native Buildpacks, and OpenTelemetry conventions, creating more standardized artifacts while preserving the managed platform experience.[18] The January 2026 migration guide still requires manual movement from Cedar Private Spaces to Fir. Teams must check ARM dependencies, IPv6 behavior, buildpacks, and add-on availability; standards do not remove those compatibility checks.[23]
Heroku competed in managed application hosting, initially around Ruby. Its differentiation was a short path from developer code to running application, plus attached services. Salesforce described the acquisition as access to developer and independent-software-vendor communities, technology, and intellectual property. It did not expect material fiscal-2012 revenue contribution.[3] This supports a strategic-platform interpretation more strongly than a near-term revenue thesis. It does not establish that Heroku lacked viable standalone economics.
The same deployment job now has mature alternatives. Render provides a Heroku migration guide covering web services, workers, Postgres, and key-value stores. Its process still involves configuration transfer, database movement, and traffic cutover.[24] Railway's June 2026 comparison describes source or container deployments, preview environments, rollbacks, and persistent volumes. Those are concrete alternatives to Heroku's workflow, although a complete move still requires database and service checks.[33] Customers need service compatibility as well as a place to run code.
As of October 2, 2026, Heroku continues to market application hosting, managed data services, enterprise features, and managed inference and agents.[1] Its February announcement said credit-card operations were unchanged and existing enterprise contracts could renew. Subsequent updates matter: March increased slug limits and build timeouts; September introduced team-level credentials with central visibility and a maximum one-year token lifetime.[5][21][22] Sustaining describes its stated investment focus, not a complete freeze on releases.
Current Cedar list prices include a $5 monthly Eco subscription and a $7 monthly always-on Basic dyno. Eco sleeps after inactivity and its shared capacity differs from a per-dyno Basic purchase. These October 2026 prices describe current entry products, not acquisition-era unit economics.[18]
Heroku monetized runtime capacity, attached services, managed data products, and enterprise relationships. Cedar's launch shifted billing from whole dynos to dyno-hours while including 750 free dyno-hours per application. The add-on marketplace extended the commercial surface through managed and third-party services.[9][13]
At acquisition, Salesforce announced approximately $212 million of cash consideration net of acquired cash. It separately described about $27 million of restricted stock and restricted stock units for employees and roughly $10 million of cash payments for unvested shares.[3][7]
The Salesforce Form 10-Q for the quarter ended July 31, 2011 reported $216.7 million of actual cash consideration. Its preliminary allocation comprised $181.5 million goodwill, $40.1 million intangibles, and $5.2 million net tangible assets, less $10.1 million deferred tax liabilities. Results were consolidated from January 3. The announcement estimate and closing accounting have different dates and bases.[4]
The reviewed sources do not establish Heroku's standalone revenue, ARR, paid-customer count, conversion, retention, gross margin, or burn at acquisition. Application counts demonstrate platform usage, not paying customers or profitability.
Heroku moved from more than 60,000 applications in May 2010 to more than 105,000 at announcement and more than 110,000 at close. Salesforce said 2,600 applications had been added in the week preceding the announcement. The acquisition announcement named FlightCaster and Best Buy as users.[3]
By June 2012, Cedar had more than 80,000 developers and 4.5 million deployments.[15] YC's profile also lists a team of 300 and platform-volume claims, but supplies no measurement date. Those figures cannot establish October 2026 headcount, activity, or commercial performance.[2]
Salesforce's stated acquisition thesis was developer reach and platform capability. Heroku's founders also expected stronger enterprise sales, support, compliance, and access to larger customers. Their contemporaneous explanation supports that distribution thesis, although it does not establish how much revenue the combination produced.[32] The subsequent product record shows technical expansion and long operating life, followed by a narrower investment focus.
The later operating record tests the limits of that abstraction. In 2013, Heroku acknowledged that Bamboo routing documentation and queue-time measurements had become inaccurate while engineering focused on Cedar. That left customers without a dependable view of performance.[10] Ending free plans in 2022 addressed fraud and abuse costs, according to management; it changed access to the product without establishing why the original company sold.[11]
The 2022 security incident exposed a different dependency. Heroku's June review said a compromised machine-account token enabled database access on April 7. Stolen GitHub OAuth tokens enabled access to Heroku repositories and a small number of customer private repositories. Heroku revoked dashboard integration tokens on April 15, rotated customer accounts on May 5 after hashed-password exfiltration, and notified affected pipeline-configuration customers on May 18. It could not definitively identify the initiating third-party integration. At publication, it reported no evidence of further access by that actor since April 14.[19] GitHub separately confirmed theft of third-party OAuth tokens; this was not evidence that GitHub itself had been breached.[20] These historical findings do not establish a current compromise.
In June 2025, an unintended system update restarted networking without restoring routing rules. Internal response tools and the status page depended on the same affected infrastructure. The company reported up to 24 hours of downtime for many customers, with no security breach or data loss.[12] Hiding infrastructure did not eliminate its failure modes; it concentrated responsibility for recovery and communication.

For customers, the long-lived abstraction and add-on model create a practical governance problem. An application can appear portable at the source-code level while depending on runtime behavior, build artifacts, attached databases, queues, storage, environment configuration, operational knowledge, and recovery assumptions. Fir's use of OCI images and Cloud Native Buildpacks is an enabling condition for portability, not proof that a workload is exit-ready.
A possible adjacent product is a neutral record of dependency ownership, tested exports, replacement choices, and recovery exercises. Demand remains a hypothesis. Existing service catalogs and readiness scorecards already cover part of this work. A new registry would need to show that versioned exit evidence solves a problem those tools leave unresolved.[25][26]