Skip to content
CF-Puppeteer is a zero-downtime deployment plugin bases on autopilot
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


cf plugin for hands-off, zero downtime application deploys


This project was forked from contraband.

It was renamed to cf-puppeteer and is being further developed under the new name.


To get an overview of the changes between versions, read the changelog.


The latest version of CF-Puppeteer is 0.0.14. It works with and is based on Cloud Foundry CLI version 6.43.0.

For more details on the most recent release, check out the changelog.

cf installation

Download the latest version from the releases page and make it executable.

$ cf install-plugin path/to/downloaded/binary


$ cf zero-downtime-push \
    -f path/to/new_manifest.yml \
    -p path/to/new/path
    -t 120

To get more information go to CF-Puppeteer homepage

passing an application name

To override the application name from the manifest, specify it as command line argument. For example:

$ cf zero-downtime-push application-to-replace \
    -f path/to/new_manifest.yml \
    -p path/to/new/path
    -t 120

changing the health check settings

To have more control over the health checks of your application, CF-Puppeteer supports additional parameters. For example:

$ cf zero-downtime-push application-to-replace \
    -f path/to/new_manifest.yml \
    -p path/to/new/path
    -t 120
    --health-check-type http
    --health-check-http-endpoint /health
    --invocation-timeout 10

While CF-Puppeteer gives precedence to command line parameters, you can also specify health-check-type and health-check-http-endpoint in the application manifest. However, Cloud Foundry currently does not support invocation-timeout in application manifests. Therefore, if you want to set it, always use the command line.


CF-Puppeteer takes a different approach compared to other zero-downtime plugins. It does not perform any complex route re-mappings. Instead it uses the manifest feature of the Cloud Foundry CLI. The method also has the advantage of treating a manifest as the source of truth and will converge the state of the system towards that. This makes the plugin ideal for continuous delivery environments.

  1. The old application is renamed to <APP-NAME>-venerable. It keeps its old route mappings. This change is invisible to users.

  2. The new application is pushed to <APP-NAME> (assuming that the name has not been changed in the manifest). It binds to the same routes as the old application (due to them being defined in the manifest) and traffic begins to be load-balanced between the two applications.

  3. The old application is deleted along with its route mappings. All traffic now goes to the new application.

local development

for local development you need to install govendor

You can’t perform that action at this time.