Page last updated:
The Cloud Controller provides REST API endpoints for clients to access the system. The Cloud Controller maintains a database with tables for orgs, spaces, services, user roles, and more.
Refer to the following diagram for information about internal and external communications of the Cloud Controller.
View a larger version of this image.
The Cloud Controller database has been tested with Postgres and MySQL.
To stage and run apps, Cloud Foundry manages and stores the following types of binary large object (blob) files:
|Blob Type||Description||Location in Blobstore|
|App Packages||Full contents of app directories, including source code and resource files, zipped into single blob files.||
|Buildpacks||Buildpack directories, which Diego cells download to compile and stage apps with.||
|Resource Cache||Large files from app packages that the Cloud Controller stores with a SHA for later re-use. To save bandwidth, the Cloud Foundry Command Line Interface (cf CLI) only uploads large application files that the Cloud Controller has not already stored in the resource cache.||
|Buildpack Cache||Large files that buildpacks generate during staging, stored for later re-use. This cache lets buildpacks run more quickly when staging apps that have been staged previously.||
|Droplets||Staged apps packaged with everything needed to run in a container.||
Cloud Foundry blobstores use the Fog Ruby gem to store blobs in
services like Amazon S3, WebDAV, or the NFS filesystem. The file system location of an internal blobstore is
A single blobstore typically stores all five types of blobs, but you can configure the Cloud Controller to use separate blobstores for each type.
After a blob deletion fails silently or something else goes wrong, the blobstore may contain blobs that the Cloud Controller no longer needs or lists in its database. These are called orphan blobs, and they waste blobstore capacity.
The Cloud Controller detects and removes orphan blobs by scanning part of the blobstore daily and checking for any blobs that its database does not account for. The process scans through the entire blobstore every week, and only removes blobs that show as orphans for three consecutive days.
The Cloud Controller performs this automatic cleanup when the
cloud_controller_worker job property
cc.perform_blob_cleanup is set to
The Cloud Controller does not track resource cache and buildpack cache blob types in its database, so it does not clean them up automatically as it does with app package, buildpack, and droplet type blobs.
To clean up the buildpack cache, admin users can run
cf curl -X DELETE /v2/blobstores/buildpack_cache. This empties the buildpack cache completely, which is a safe operation.
To clean up the resource cache, delete it as follows:
- Internal blobstore: Run
bosh sshto connect to the blobstore VM (NFS or WebDav) and
rm *the contents of the
- External blobstore: Use the file store’s API to delete the contents of the
Do not manually delete app package, buildpack, or droplet blobs from the blobstore. To free up resources from those locations, run
cf delete-buildpack for buildpacks or
cf delete for app packages and droplets.
rspec runs a test suite with the SQLite in-memory database.
Specify a connection string using the
DB_CONNECTION environment variable to
test against Postgres and MySQL. For example:
DB_CONNECTION="postgres://postgres@localhost:5432/ccng" rspec DB_CONNECTION="mysql2://root:password@localhost:3306/ccng" rspec
Travis currently runs two build jobs against Postgres and MySQL.
For more information about how Cloud Foundry aggregates and streams logs and metrics, see the Overview of the Loggregator System topic.Create a pull request or raise an issue on the source for this page in GitHub