Are you happy with your logging solution? Would you help us out by taking a 30-second survey? Click here


Java Client Library for Cloud Foundry

Subscribe to updates I use cf-java-client

Statistics on cf-java-client

Number of watchers on Github 244
Number of open issues 19
Average time to close an issue 6 days
Main language Java
Average time to merge a PR about 11 hours
Open pull requests 20+
Closed pull requests 137+
Last commit over 1 year ago
Repo Created about 8 years ago
Repo Last Updated over 1 year ago
Size 47 MB
Organization / Authorcloudfoundry
Latest Releasev3.8.0.RELEASE
Page Updated
Do you use cf-java-client? Leave a review!
View open issues (19)
View cf-java-client activity
View on github
Fresh, new opensource launches πŸš€πŸš€πŸš€
Trendy new open source projects in your inbox! View examples

Subscribe to our mailing list

Evaluating cf-java-client for your project? Score Explanation
Commits Score (?)
Issues & PR Score (?)

Cloud Foundry Java Client

Reactor Version Cloud Foundry Java Client Version
Reactor 3.1 Maven Central
Reactor 3.0 Maven Central
Artifact Javadocs
cloudfoundry-client Javadocs
cloudfoundry-client-reactor Javadocs
cloudfoundry-operations Javadocs
cloudfoundry-util Javadocs
Job 3.x Status 2.x Status
unit-test unit-test-master unit-test-2.x
integration-test-1.10 unit-test-master unit-test-2.x
integration-test-1.11 unit-test-master unit-test-2.x
integration-test-1.12 unit-test-master unit-test-2.x
integration-test-2.0 unit-test-master unit-test-2.x
deploy deploy-master deploy-2.x

The cf-java-client project is a Java language binding for interacting with a Cloud Foundry instance. The project is broken up into a number of components which expose different levels of abstraction depending on need.

  • cloudfoundry-client Interfaces, request, and response objects mapping to the Cloud Foundry REST APIs. This project has no implementation and therefore cannot connect a Cloud Foundry instance on its own.
  • cloudfoundry-client-reactor The default implementation of the cloudfoundry-client project. This implementation is based on the Reactor Netty HttpClient.
  • cloudfoundry-operations An API and implementation that corresponds to the Cloud Foundry CLI operations. This project builds on the cloudfoundry-client and therefore has a single implementation.


Most projects will need two dependencies; the Operations API and an implementation of the Client API. For Maven, the dependencies would be defined like this:


Snapshot artifacts can be found in the Spring snapshot repository:

        <name>Spring Snapshots</name>

For Gradle, the dependencies would be defined like this:

dependencies {
    compile 'org.cloudfoundry:cloudfoundry-client-reactor:3.5.0.RELEASE'
    compile 'org.cloudfoundry:cloudfoundry-operations:3.5.0.RELEASE'
    compile 'io.projectreactor:reactor-core:3.1.5.RELEASE'
    compile 'io.projectreactor.ipc:reactor-netty:0.7.5.RELEASE'

Snapshot artifacts can be found in the Spring snapshot repository:

repositories {
    maven { url '' }


Both the cloudfoundry-operations and cloudfoundry-client projects follow a Reactive design pattern and expose their responses with Project Reactor Monoss and Fluxs.

CloudFoundryClient, DopplerClient, UaaClient Builders

The lowest-level building blocks of the API are ConnectionContext and TokenProvider. These types are intended to be shared between instances of the clients, and come with out of the box implementations. To instantiate them, you configure them with builders:



In Spring-based applications, you'll want to encapsulate them in bean definitions:

DefaultConnectionContext connectionContext(@Value("${cf.apiHost}") String apiHost) {
    return DefaultConnectionContext.builder()

PasswordGrantTokenProvider tokenProvider(@Value("${cf.username}") String username,
                                         @Value("${cf.password}") String password) {
    return PasswordGrantTokenProvider.builder()

CloudFoundryClient, DopplerClient, and UaaClient are only interfaces. Each has a Reactor-based implementation. To instantiate them, you configure them with builders:




In Spring-based applications, you'll want to encapsulate them in bean definitions:

ReactorCloudFoundryClient cloudFoundryClient(ConnectionContext connectionContext, TokenProvider tokenProvider) {
    return ReactorCloudFoundryClient.builder()

ReactorDopplerClient dopplerClient(ConnectionContext connectionContext, TokenProvider tokenProvider) {
    return ReactorDopplerClient.builder()

ReactorUaaClient uaaClient(ConnectionContext connectionContext, TokenProvider tokenProvider) {
    return ReactorUaaClient.builder()

CloudFoundryOperations Builder

The CloudFoundryClient, DopplerClient, and UaaClients provide direct access to the raw REST APIs. This level of abstraction provides the most detailed and powerful access to the Cloud Foundry instance, but also requires users to perform quite a lot of orchestration on their own. Most users will instead want to work at the CloudFoundryOperations layer. Once again this is only an interface and the default implementation of this is the DefaultCloudFoundryOperations. To instantiate one, you configure it with a builder:

NOTE: The DefaultCloudfoundryOperations type does not require all clients in order to run. Since not all operations touch all kinds of clients, you can selectively configure the minimum needed. If a client is missing, the first invocation of a method that requires that client will return an error.


In Spring-based applications, you'll want to encapsulate this in a bean definition as well:

DefaultCloudFoundryOperations cloudFoundryOperations(CloudFoundryClient cloudFoundryClient,
                                                     DopplerClient dopplerClient,
                                                     UaaClient uaaClient,
                                                     @Value("${cf.organization}") String organization,
                                                     @Value("${}") String space) {
    return DefaultCloudFoundryOperations.builder()

CloudFoundryOperations APIs

Once you've got a reference to the CloudFoundryOperations, it's time to start making calls to the Cloud Foundry instance. One of the simplest possible operations is list all of the organizations the user is a member of. The following example does three things:

  1. Requests a list of all organizations
  2. Extracts the name of each organization
  3. Prints the name of the each organization to System.out

To relate the example to the description above the following happens:

  1. .list() Lists the Cloud Foundry organizations as a Flux of elements of type Organization.
  2. .map(...) Maps each organization to its name (type String). This example uses a method reference; the equivalent lambda would look like organizationSummary -> organizationSummary.getName().
  3. subscribe... The terminal operation that receives each name in the Flux. Again, this example uses a method reference and the equivalent lambda would look like name -> System.out.println(name).

CloudFoundryClient APIs

As mentioned earlier, the cloudfoundry-operations implementation builds upon the cloudfoundry-client API. That implementation takes advantage of the same reactive style in the lower-level API. The implementation of the Organizations.list() method (which was demonstrated above) looks like the following (roughly):

    .map(resource -> OrganizationSummary.builder()

The above example is more complicated:

  1. .list(...) Retrieves a page of Cloud Foundry organizations.
  2. .flatMapIterable(...) Substitutes the original Mono with a Flux of the Resources returned by the requested page.
  3. .map(...) Maps the Resource to an OrganizationSummary type.


The project depends on Java 8. To build from source and install to your local Maven cache, run the following:

$ git submodule update --init --recursive
$ ./mvnw clean install

To run the integration tests, run the following:

$ ./mvnw -Pintegration-test clean test

IMPORTANT Integration tests should be run against an empty Cloud Foundry instance. The integration tests are destructive, affecting nearly everything on an instance given the chance.

The integration tests require a running instance of Cloud Foundry to test against. We recommend using PCF Dev to start a local instance to test with. To configure the integration tests with the appropriate connection information use the following environment variables:

Name Description
TEST_ADMIN_CLIENTID Client ID for a client with permissions for a Client Credentials grant
TEST_ADMIN_CLIENTSECRET Client secret for a client with permissions for a Client Credentials grant
TEST_ADMIN_PASSWORD Password for a user with admin permissions
TEST_ADMIN_USERNAME Username for a user with admin permissions
TEST_APIHOST The host of a Cloud Foundry instance. Typically something like
TEST_PROXY_HOST (Optional) The host of a proxy to route all requests through
TEST_PROXY_PASSWORD (Optional) The password for a proxy to route all requests through
TEST_PROXY_PORT (Optional) The port of a proxy to route all requests through. Defaults to 8080.
TEST_PROXY_USERNAME (Optional) The username for a proxy to route all requests through
TEST_SKIPSSLVALIDATION (Optional) Whether to skip SSL validation when connecting to the Cloud Foundry instance. Defaults to false.


Pull requests and Issues are welcome.


This project is released under version 2.0 of the Apache License.

cf-java-client open issues Ask a question     (View All Issues)
  • almost 3 years Rewrite to offer better fault options
  • almost 3 years Not possible to bind a service that has null values in credentials map
  • about 3 years Cannot created 'DefaultConnectionContext' (may be caused by 'eureka')
  • about 3 years Consider sending token auth data via post body instead of uri parameters
  • about 3 years CF client Invalid auth token error
  • about 3 years Not Available in Maven Central
  • about 3 years Client "hangs" until timeout when 40x is returned from get token request
  • about 3 years Cannot get answer from a statistics request
  • about 3 years Timeout Creating Service
  • about 3 years Why currentVariant is being removed ?
  • about 3 years Knowing the bound services
  • about 3 years Recent log: Some messages are not well read
  • about 3 years GetApplicationRequest throwing staging error for a stopped app
  • about 3 years Knowing the application state
  • over 3 years Could the client detect proxy configuration from the 'environment'?
  • over 3 years Set Env variables on push
  • over 3 years Allow multiple hosts to be mapped when deploying using gradle
  • over 3 years Create unique route while pushing to Bluemix from inside a maven build file
  • almost 4 years Add support for .cfignore file
  • about 5 years Add support for storing properties in a manifest.yaml
cf-java-client open pull requests (View All Pulls)
  • V1.1.2 - This commit fixes the issue #363, where upload status was not set for…
  • Delete Security Group Running Default
  • Create buildpack operation
  • Marketplace operation
  • use HttpComponentsClientHttpRequestFactory with HttpClient
  • v1.1.2 Fix for issue #351
  • Create Identity Zone Client
  • Create Identity Provider
  • Update User Provided Service instance
  • Create Service Broker operation
  • 101522656 create security groups
  • Identity providers
  • Returning Envelope as part of the Firehose response
  • Delete Identity Provider
  • Authorized grant type
  • Fix Create/Update client requests
  • Gradle Plugin for managing an application in Cloud Foundry environment
  • Refresh token expiration
  • Clean up of deprecated HttpStart and HttpStop entries
  • Manually add content-length header to authentication request
cf-java-client list of languages used
cf-java-client latest release notes
v3.8.0.RELEASE Cloud Foundry Java Client 3.8.0.RELEASE

I'm pleased to announce the release of the Cloud Foundry Java Client, version 3.8.0.RELEASE. This release focuses on fixing a bug in service plans.

  • Fix deserialisation error when getting service plans (via @andreaAlkalay)

For a more detailed look at the changes in 3.8.0.RELEASE, please take a look at the issue tracker and commit log.

v2.27.0.RELEASE Cloud Foundry Java Client 2.27.0.RELEASE

I'm pleased to announce the release of the Cloud Foundry Java Client, version 2.27.0.RELEASE. This release focuses on fixing a bug in service plans.

  • Fix deserialisation error when getting service plans (via @andreaAlkalay)

For a more detailed look at the changes in 2.27.0.RELEASE, please take a look at the issue tracker and commit log.

v3.6.0.RELEASE Cloud Foundry Java Client 3.6.0.RELEASE

I'm pleased to announce the release of the Cloud Foundry Java Client, version 3.6.0.RELEASE. This release focuses on bug fixes.

  • Resolve a 'The app package is invalid: bits have not been uploaded' error when pushing an application.
  • Update Quota operations to match the latest CLI functionality (via @andreaAlkalay)
  • Resolve a firehose Netty leak (via Mike Youngstrom)
  • Resolve a token provider NPE (via @andreaAlkalay)
  • Application Tasks functionality, and improved integration tests.

For a more detailed look at the changes in 3.6.0.RELEASE, please take a look at the issue tracker and commit log.

Other projects in Java