Need help with cloud_controller_ng?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

162 Stars 345 Forks Apache License 2.0 13.4K Commits 132 Opened issues


Cloud Foundry Cloud Controller

Services available


Need anything else?

Contributors list

Build Status Code Climate Code Climate

Welcome to the Cloud Controller

Helpful Resources


Cloud Controller

The Cloud Controller provides REST API endpoints to create and manage apps, services, user roles, and more!


The Cloud Controller supports Postgres and Mysql.


The Cloud Controller manages a blobstore for:

All Platforms: * Resource cache: During package upload resource matching, Cloud Controller will only upload files it doesn't already have in this cache.

When deployed via capi-release only: * App packages: Unstaged files for an application * Droplets: An executable containing an app and its runtime dependencies * Buildpacks: Set of programs that transform packages into droplets * Buildpack cache: Cached dependencies and build artifacts to speed up future staging

Cloud Controller currently supports webdav and the following fog connectors:

  • Alibaba Cloud (Experimental)
  • Azure
  • Openstack
  • Local (NFS)
  • Google
  • AWS


The Cloud Controller on VMs uses Diego to stage and run apps and tasks. See Diego Design Notes for more details.

When deployed on Kubernetes, Cloud Controller uses kpack to build images from source with Cloud Native Buildpacks and Eirini to run apps directly on the Kubernetes cluster.


Please read the contributors' guide and the Cloud Foundry Code of Conduct

Unit Tests

TLDR: Always run

bundle exec rake
before committing

To maintain a consistent and effective approach to testing, please refer to the spec README and keep it up to date, documenting the purpose of the various types of tests.

By default

will randomly pick between postgres and mysql.

If postgres is not running on your OSX machine, you can start up a server by doing the following:

brew services start postgresql
createuser -s postgres
DB=postgres rake db:create

It will try to connect to those databases with the following connection string:

To specify a custom username, password, host, or port for either database type, you can override the default connection string prefix (the part before the

database name) by setting the
variables. Alternatively, to override the full connection string, including the database name, you can set the
environment variable. This will restrict you to only running tests in serial, however.

For example, to run unit tests in parallel with a custom mysql username and password, you could execute:

MYSQL_CONNECTION_PREFIX=mysql2://custom_user:[email protected]:3306 bundle exec rake

The following are examples of completely fully overriding the database connection string:

DB_CONNECTION_STRING="postgres://[email protected]:5432/cc_test" DB=postgres rake spec:serial
DB_CONNECTION_STRING="mysql2://root:[email protected]:3306/cc_test" DB=mysql rake spec:serial

If you are running the integration specs (which are included in the full rake), and you are specifying

, you will also need to have a second test database with
as the name suffix.

For example, if you are using:

DB_CONNECTION_STRING="postgres://[email protected]:5432/cc_test"

You will also need a database called:


The command

rake db:create
will create the above database when the
environment variable is set to postgres or mysql. You should run this before running rake in order to ensure that the
database exists.

Running tests on a single file

The development team typically will run the specs to a single file as (e.g.)

bundle exec rspec spec/controllers/runtime/users_controller_spec.rb

Running all the unit tests

bundle exec rake spec

Note that this will run all tests in parallel by default. If you are setting a custom

, you will need to run the tests in serial instead:
bundle exec rake spec:serial

To be able to run the unit tests in parallel and still use custom connection strings, use the

environment variables described above.

Running static analysis

bundle exec rubocop

Running both unit tests and rubocop

By default,

bundle exec rake
will run the unit tests first, and then
if they pass. To run
first, run:
RUBOCOP_FIRST=1 bundle exec rake


Cloud Controller uses Steno to manage its logs. Each log entry includes a "source" field to designate which module in the code the entry originates from. Some of the possible sources are '', 'cc.app_stager', and 'cc.healthmanager.client'.

Here are some use cases for the different log levels: *

- the CC received a malformed HTTP request, or a request for a non-existent droplet *
- the CC failed to delete a droplet, CC received a request with an invalid auth token *
- CC received a token from UAA, CC received a NATS request *
- CC created a service, updated a service *
- CC syncs resource pool, CC uploaded a file


The Cloud Controller uses a YAML configuration file. For an example, see


We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.