Cloud Foundry Projects

The Cloud Foundry API (CAPI) is the interface for the platform's functionality, orchestrating a user's interactions with the system. This team is in charge of designing, architecting, and prioritizing development work that keeps the API flexible, consistent, and extensible.

The CF CLI is the certified command-line client that enables developers to interact with the Cloud Foundry platform and its services. This team oversees its development and prioritizes improvements / additions to this crucial developer experience component.

The Container to Container Networking (c2c) project is focused on developing a Garden-runC add-on capability that provides container networking for the Cloud Foundry platform.

Diego is the new container runtime for Cloud Foundry, replacing the architecture build on DEAs and Health Manager, and making it possible to turn Docker applications into Cloud Foundry services. Diego is able to take a Docker image and create a container in which the same processes run seamlessly, making the best use of these popular technologies available to those seeking a modern application platform system. The PMC is responsible for maintaining and innovating on this container-based runtime.

The Diego Persistence (Persi) project adds the ability to attach data services that have a filesystem-based interface to the Cloud Foundry platform. Examples of this are Volume Mounts on Service Brokers and Volume Drivers on Diego Cells.

Eirini is a project to provide pluggable scheduling for the Cloud Foundry Application Runtime. Eirini is initially specifically focused on allowing operators to choose between Diego (the “batteries included” default scheduler in CFAR) and Kubernetes (whether via CFCR or via external Kubernetes-as-a-Service providers) as the container orchestrator used for application container instances. The aim is to give operators the option of combining the “cf push” developer experience with the Kubernetes operator experience.

Garden is a secure container API and runtime at the core of the certified Cloud Foundry platform and can be backed by both Linux and Windows backends. This PMC team continues to manage the container back end development and the many “pluggable” pieces of software responsible for creating containers.

The Garden Windows (Greenhouse) team works on adding a Windows backend for Garden and enabling .NET development on the Cloud Foundry platform.

HAProxy BOSH Release is a general-purpose software-based load-balancer that can act as a gateway to Cloud Foundry. It provides installations with SNI SSL support, domain-based access control, WebSockets support in HTTP mode, and more.

The Cloud Foundry infrastructure team is responsible for the backbone components of the Cloud Foundry platform (such as etcd and Consul), which are also used within other systems. This team is also building tooling for setting up IaaS environments and BOSH directors to improve the getting started experience for OSS users of Cloud Foundry and Concourse on AWS and GCP.

Log Aggregator (Loggregator) is the Cloud Foundry component that provides a non-persistent stream of log output either from an application or from Cloud Foundry runtime components. These logs can be drained into third-party log management software such as Splunk, Logstash, New Relic, Datadog and Dynatrace. The Loggregator PMC oversees enhancements and further capability development for the overall metrics & logging functionality.

This team is in charge of creating a highly-available mySQL database to the Cloud Foundry platform, which will then be provided as a service to application developers.

CF Permissions is an incubating project focused on improving the authorization experience in Cloud Foundry by enabling more granular and easily-administered authorizations.

This team oversees the BOSH release for PostgreSQL database that can be attached to the Cloud Foundry platform and made available to application developers.

The CF Release Integration team is responsible for high level integration testing for the Cloud Foundry platform, final release integration pipelines, and tooling for generating BOSH deployments to deploy the platform from all its integrated components.

The Cloud Foundry Routing subsystem ensures that application requests are passed through correctly to the correct destination, be that an application or platform system component. The Routing project also owns the development of operator and developer user experience for managing routes and domains.

The Services API project has set out to enhance the developer workflow on Cloud Foundry provisioning and managing services. This will be done by adding improvements to the Cloud Controller and Open Service Broker API, and working closely with the Cloud Foundry CLI project to expose new features and enhancements.

This team is focused on prioritizing and building features to simplify the identity management of users and user accounts through their Cloud Foundry credentials.