Cloud Foundry

An 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.

What it is: Platform as a service (PaaS)
Type: Open source
Made by: Cloud Foundry Foundation
License: Apache 2.0
Facts checked: 12 October 2026

What it is

A developer runs cf push. The CLI asks the Cloud Controller to create the app, uploads only the files its resource cache doesn’t already have, and the Cloud Controller stores the package in the blobstore. Diego then runs a staging task on a cell: it downloads the buildpacks, compiles the app and saves the result, a tarball called a droplet, back to the blobstore. Staging that takes longer than 15 minutes fails. Docker images skip this step: Diego reads the image’s metadata and runs its start command.

Diego is the scheduler. Its Bulletin Board System (BBS), backed by MySQL, holds the desired number of instances for each app (DesiredLRP) and what is actually running (ActualLRP); a convergence loop starts or stops instances until the two match, and an auction picks which cell gets each one. Instances run as Garden containers on Diego cell VMs. A route emitter on each cell tells the Gorouter, through NATS, where every instance listens, and the Gorouter sends requests for an app’s routes to those instances. Databases and other services come from service brokers: binding a service instance puts its credentials into the app’s VCAP_SERVICES environment variable on the next restart.

The platform itself is a set of VMs that operators deploy with BOSH onto vSphere, OpenStack or a public cloud. The project belongs to the Cloud Foundry Foundation, a directed fund of the Linux Foundation. Attempts to rebuild it on Kubernetes (Eirini, cf-for-k8s and Korifi, which was archived on September 15, 2026) have all been retired; the current approach, from an SAP team, keeps Cloud Foundry unchanged and only swaps how a container is created, so it runs on any Kubernetes cluster and passes the full acceptance test suite.

Why teams pick it

The same cf push and app manifest work on any infrastructure BOSH can deploy to, in your own data center or in a public cloud
Self-healing by design: Diego keeps comparing desired and actual instances and replaces any that crash or disappear
Runs classic buildpacks and Cloud Native Buildpacks, as well as prebuilt Docker images
Services are bound through brokers, so apps get credentials in VCAP_SERVICES instead of hard-coded config

Watch out for

Operating it is a job: many components (Cloud Controller, UAA, Diego, Gorouter, Loggregator, BOSH) to deploy, upgrade and rotate certificates for
The docs advise against more than 250 Diego cells per deployment, because changes to a larger foundation can take days or weeks to roll out
Kubernetes ports have come and gone: Eirini, cf-for-k8s and Korifi are archived, and Korifi never covered the whole Cloud Foundry API
Environment variables, including VCAP_SERVICES, are capped at 130 KB, and credentials should not go in user-provided env vars because they can show up in CLI output and logs

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.

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.

HerokuCommercialThe 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.

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

What Cloud Foundry uses

manifest.yml read by `cf push` · yaml

---
applications:
- name: my-app
  memory: 512M
  instances: 2
  buildpacks:
  - go_buildpack
  env:
    GOPACKAGENAME: go_calls_ruby
  command: go_calls_ruby
  routes:
  - route: www.example.com/foo
  services:
  - service-1

See it in a real stack

No architecture uses Cloud Foundry yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2009–2026

Cloud Foundry was conceived at VMware in 2009 by a small team led by Derek Collison, under the code name Project B29. VMware released Cloud Foundry on April 12, 2011, with the code on GitHub under Apache 2.0 and a design it called “multi-cloud”: the same platform for private data centers and public clouds, supporting Java, Ruby, Node.js, MySQL, MongoDB and Redis from the start.

BOSH, the tool that deploys and manages the platform’s VMs, was published in April 2012. In 2013 the project moved to Pivotal, a company formed by EMC and VMware, and in January 2015 it went to the new Cloud Foundry Foundation, a Linux Foundation project, with open governance; its membership reached 65 companies by February 2019. The platform adopted Heroku’s buildpacks and handed app scheduling from the Cloud Controller to Diego, and in December 2016 the Open Service Broker API, which apps use to reach external services, was launched.

As Kubernetes spread, the community tried several times to run Cloud Foundry on it. Eirini, cf-for-k8s and Korifi each replaced a piece of Cloud Foundry with a Kubernetes equivalent and behaved slightly differently. Korifi’s maintainers, three SAP employees, proposed archiving it in July 2026 for lack of interest, and in October 2026 an SAP team showed the opposite approach: Cloud Foundry left intact, with Diego creating Pods instead of Garden containers.

Why it’s built this way

Open source and multi-cloud from day one: VMware pitched it as a platform that works across private and public clouds and many frameworks, and put the code on GitHub under Apache 2.0, so anyone could run it.
Desired state with convergence: Apps run on many VMs that can crash or vanish. Diego stores the desired and actual instance counts in its BBS and keeps starting or stopping instances until they match, rather than starting instances once and hoping they stay up.
Services through brokers: A broker provisions a service instance and hands its credentials to bound apps, so an app reads VCAP_SERVICES the same way whether the database is managed by the platform team or a third party.
On Kubernetes, change only container creation: Earlier ports changed scheduling, staging or the API and broke existing apps and scripts. Implementing Diego’s garden.Client interface against the Kubernetes API keeps everything above it unchanged, so the standard acceptance tests pass at 100%.

Timeline

2009
Conceived at VMware as Project B29
2011
VMware releases Cloud Foundry under Apache 2.0 on April 12
2012
BOSH is released in April
2015
The Cloud Foundry Foundation is formed as a Linux Foundation project in January
2016
The Open Service Broker API launches in December
2026
Korifi is archived on September 15; Cloud Foundry runs unchanged on any Kubernetes cluster (October)

Sources12 · facts checked 12 October 2026

Improve this page on GitHub