An official website of the United States government US flag signifying that this is a United States federal government website

Continuous deployment

Continuous deployment

Setting up continuous deployment allows you to automatically upload your changes to your desired environment.

Get ready

Before setting up continuous deployment:

  1. Go through the production-ready guide to ensure your application uses the core best practices and zero-downtime deployment. This will help you use continuous deployment with reduced risk of errors and outages.
  2. Set up continuous integration. This will protect you from deploying a broken application. You can use the same service for continuous integration and continuous deployment — see the list of continuous integration services below for suggestions.

Provision deployment credentials

Continuous deployment systems require credentials for use in pushing new versions of your application code to You should use a restricted set of credentials that can only access a particular target space, rather than credentials tied to a user who has more access, or who may lose access when leaving your team or project. This “least privilege” approach minimizes the harm that is possible if the credentials are compromised in any way.

To provision a deployer account with permission to deploy to a single space, set up an instance of a service account.

Continuous integration services

To set up any of these services, you will need to provide a manifest.yml file that captures the intended deployment configuration for your application.


See the Travis documentation.

Use api:

You must encrypt the password, and you must escape any symbol characters in the password, to prevent possible situations where Travis could dump an error message that contains passwords or environment variables.

For more information about configuring Travis, see Customizing the Build.

Using Conditional Deployments with Travis

A common pattern for team workflows is to use separate development and master branches, along with using a staging or QA deployment with the development branch, and a production deployment with the master branch. This can be achieved in Travis with on: to specify a branch, and using unique manifests for each deployment.

- manifest: manifest-staging.yml
  # ...
    branch: develop
- manifest: manifest.yml
  # ...
    branch: master

Each manifest should at the very least define an unique name, but can also define an unique host. Also, it may be necessary to define unique services for each application to use. See Cloning Applications for more information.

Jekyll with Travis

To deploy a Jekyll site, add the following to your .travis.yml:

language: ruby
- 2.1
script: jekyll build ./_site
  skip_cleanup: true
  # ...

For details, see Jekyll’s Continuous Integration guide.


Add these items to your circle.yml file:

    - curl -v -L -o cf-cli_amd64.deb ''
    - sudo dpkg -i cf-cli_amd64.deb
    - cf -v

    - cf login -a -u DEPLOYER_USER -p $CF_PASS -o ORG -s SPACE

    branch: master
      - cf push

Replace DEPLOYER_USER, ORG, and SPACE accordingly, and export the CF_PASS environment variable in the Circle interface to add the deployer’s password.

Note: If your manifest.yml describes more than one app, you might want to specify which app to push in the cf push line.


In your wercker.yml file, add:

  - dlapiduz/cloud-foundry-deploy
    - dlapiduz/cloud-foundry-deploy:
        api: $CF_API
        username: $CF_USER
        password: $CF_PASS
        organization: $CF_ORG
        space: $CF_SPACE
        appname: APP
        domain: DOMAIN
        hostname: myapp
        skip_ssl: true

Change APP and DOMAIN to match your application, and set up the following environment variables in a “deploy target”:

Name Value
CF_USER deployer username
CF_PASS deployer password
CF_ORG target organization
CF_SPACE target space

You can also add the alt_appname attribute to do Blue-Green deploys.