Cloud Foundry is an open platform as a service (PaaS), providing a choice of clouds, developer frameworks and application services. Cloud Foundry makes it faster and easier to build, test, deploy and scale applications.
This repository contains the Cloud Foundry source code.
Our documentation, currently a work in progress, is available here: http://cloudfoundry.github.com/
The master branch is where we do active development. Although we endeavor to keep the master branch stable, we do not guarantee that any given commit will deploy cleanly.
If you want a stable branch, we recommend that you use the release-candidate branch.
This repository is structures for use with BOSH, an open source tool for release engineering, deployment and lifecycle management of large scale distributed services. The directories are:
- .final_builds
- config: pointers to dependencies cached in the BOSH blobstore.
- git
- jobs: start and stop commands for each of the jobs (processes) running on Cloud Foundry nodes.
- packages: packaging instructions used by BOSH to build each of the dependencies.
- releases: yml files containing the git commit shas for each package in a given release.
- src: the source code for the components in Cloud Foundry. Note that each of the components is a submodule with a pointer to a specific sha. So even if you do not use BOSH to deploy Cloud Foundry, the list of submodule pointers
See the documentation for deploying Cloud Foundry for more information about using BOSH.
In order to deploy Cloud Foundry with BOSH, you will need to create a manifest. You can find a sample manifest in the documentation.
The current development effort centers on V2, also known as NG. For information on what the core team is working on, please see our roadmap.
The components in a V2 deployment are:
| Component | Description | Build Status |
| Cloud Controller (ccng) | The primary entry point for Cloud Foundry. When you use vmc to push an application to Cloud Foundry, you target it against the Cloud Controller. | 
|
| gorouter | The central router that manages traffic to applications deployed on Cloud Foundry. Written in go, the v2 router represents a significant performance improvement over v1. | 
|
| DEA (dea_next) | The droplet execution agent (DEA) performs two key activities in Cloud Foundry: staging and hosting applications. |  |
| Health Manager | The health manager monitors the state of the applications and ensures that started applications are indeed running, their versions and number of instances correct. | 
|
| documentation in progress...more to come |
This repository also contains v1 legacy components. These components are not under active development and will eventually not be linked in this repository.
Questions about the Cloud Foundry Open Source Project can be directed to our Google Groups.
- BOSH Developers: https://groups.google.com/a/cloudfoundry.org/group/bosh-dev/topics
- BOSH Users:https://groups.google.com/a/cloudfoundry.org/group/bosh-users/topics
- VCAP (Cloud Foundry) Developers: https://groups.google.com/a/cloudfoundry.org/group/vcap-dev/topics
Bugs can be filed using Github Issues within the various repositories of the Cloud Foundry components.
The Cloud Foundry team uses GitHub and accepts contributions via pull request
Follow these steps to make a contribution to any of our open source repositories:
-
Complete our CLA Agreement for individuals or corporations
-
Set your name and email
git config --global user.name "Firstname Lastname" git config --global user.email "your_email@youremail.com" -
Fork the repo
-
Make your changes on a topic branch, commit, and push to github and open a pull request.
Your pull request is much more likely to be accepted if:
-
It is small and focused with a clear commit message that conveys the intent behind your change.
-
The tests pass in CI (we use Travis CI for many of our components in large part because of their excellent support for pull requests).
-
Your pull request includes tests.
We review pull requests regularly.