Cloud Foundry vs Heroku

What Cloud Foundry is

Cloud Foundry is an Apache-licensed, openly governed application-platform ecosystem. Developers push supported application code through the cf CLI and platform API; operators provide routing, buildpacks, container scheduling, identity, logs, quotas and service integrations. The software has no license fee, but a production foundation still requires infrastructure, load balancers, DNS/TLS, databases, blob stores, monitoring, backups, updates and skilled operations—or a separately priced commercial distribution or managed provider. Certification verifies required core components for a specific program year; it is not the same as generic API compatibility or an uptime guarantee.

What Heroku is

Heroku is a proprietary platform as a service that builds and runs applications in managed dyno containers, with pipelines, logs, data products and marketplace add-ons. Eco provides 1,000 shared personal-account dyno hours for $5 monthly and sleeps inactive web apps; Basic and larger dynos are usage-prorated up to published monthly caps. Dyno filesystems are ephemeral, so durable state belongs in databases or object storage. Compute, data services, add-ons, CI, support and private networking must be costed together.

What Cloud Foundry is built to do

cf push workflow

Stages supported source or artifacts with buildpacks and schedules application instances.

Organizations and spaces

Scopes applications, routes, services, quotas and role-based access for multiple teams.

Service broker model

Provisions and binds managed services through the Open Service Broker API.

UAA identity

Provides OAuth-based platform identity with configurable LDAP and SAML federation.

What Heroku is built to do

Managed dynos

Runs isolated application processes with platform-managed cycling and replacement.

Release workflow

Builds deployable releases and supports pipelines, review apps and one-off administrative processes.

Data and add-ons

Attaches Heroku data products and third-party marketplace services to applications.

Runtime tiers

Offers sleeping personal Eco dynos through always-on production and isolated Private/Shield options.

Choose Cloud Foundry if

• Large application portfolios that conform to buildpack or supported container workflows
• Organizations prioritizing consistent developer experience across infrastructure choices
• Internal platforms with dedicated owners for upgrades, security, observability and disaster recovery

Skip Cloud Foundry if

• The organization has only a few simple services and no platform-operations capacity
• Applications require privileged hosts, unusual kernels or infrastructure-level control
• The selected distribution has no verified lifecycle, support, certification or backup responsibility

Choose Heroku if

• Conventional stateless web and worker applications needing fast deployment and managed runtime operations
• Small experiments on Eco where sleep and the shared 1,000-hour pool are acceptable
• Production services after sizing dynos, databases, add-ons, regions and support as one bill

Skip Heroku if

• The application needs persistent local disk, privileged host access or unusual infrastructure control
• Cold starts, a single Eco dyno per process type or hour exhaustion are unacceptable
• Data residency is assumed from the app region without reviewing control-plane and add-on behavior

Cloud Foundry: pros & cons

• Developer abstraction: A consistent cf push workflow hides much of the infrastructure configuration from application teams.
• Open governance and source: Foundation projects use open contribution, design and governance processes.
• Infrastructure choice: Cloud Foundry can be deployed on multiple IaaS environments or consumed through commercial offerings.
• Platform controls: UAA identity, RBAC, orgs, spaces, quotas, routing, logs and service brokers provide multi-team governance.
• Free software has real operating cost: Production topology, infrastructure, upgrades, security and recovery need a platform team.
• Provider experience varies: Buildpacks, services, extensions, support, certification and pricing differ among distributions.
• State remains external: Databases and bound services need their own durability, credential and restore strategy.
• Not general compute: The opinionated application model is a poor fit for workloads needing unrestricted hosts or unusual system dependencies.

Heroku: pros & cons

• Managed runtime: Heroku handles container placement, restarts and underlying operating-system administration.
• Simple release model: Source or container deployments, configuration variables and one-off commands support repeatable application delivery.
• Integrated ecosystem: Pipelines, review apps, Postgres, Key-Value Store and marketplace add-ons reduce integration work.
• Granular billing: Most dynos and data add-ons are prorated to the second up to a monthly maximum.
• No general free compute tier: Eco costs $5 monthly, is personal-app only and can exhaust its shared hour pool.
• Eco cold starts: Inactive web dynos sleep after 30 minutes and wake with a delay.
• Ephemeral local disk: Files written at runtime disappear across restarts, deploys or dyno replacement.
• Stacked cost: Production dynos, databases, add-ons, CI, teams and support can materially exceed the headline compute price.