Skip to content
Gem for managing your bosh workspace
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.

Bosh workspace

Build Status Test Coverage Code Climate Dependency Status Stories in Ready

Depreciation Notice

BOSH workspace is intimately related to how deployment manifests were handled with BOSH v1. At the time, most projects were providing Bash-based ad-hoc toolchains for building large YAML deployment manifests out of somewhat smaller YAML pieces called Spiff templates and stubs.

In this landscape, BOSH Workspace introduced an effort for providing a standard toolchain around Spiff, giving a chance for better organizing Spiff templates and stubs into what could be called “infrastructure-as-code“ git repositories, that could precisely describe staging and production environments managed by BOSH.

Later, the development of BOSH Workspace has been abandoned in favor of other tools like Genesis v1, then v2. And on the BOSH side, the v2 CLI has deprecated Spiff and thus the way BOSH Workspace works. Plus, reference deployment manifests are progressively being distributed as *-deployment (example: bosh, cf) git repos containing a base BOSH v2 deployment along with operation files that implement variants around the base deployment. So, fewer and fewer projects are shipping Spiff templates anymore.

So, newer ways of organizing BOSH deployment manifests have emerged like Genesis that has pivoted to Genesis v2 to support BOSH v2 or Gstack BOSH Environment (or GBE for intimates) that is natively built around the BOSH v2 CLI.


BOSH Workspace is in essence a bosh v1 CLI plugin for managing an organized layout of Spiff stubs and templates that are the basis of typical BOSH v1 deployments. Such organized layout helps in managing consistently the various infrastructure-as-code environments you might have, like “sandbox”, “pre-prod” or ”production”, all made of BOSH deployments that are similar but not exactly the same.

BOSH Workspace aslo noticeably introduces new handly verbs in the bosh v1 CLI that make it easier to deploy things. Indeed, running bosh prepare deployment automates the uploading of BOSH Releases and BOSH Stemcells (the required bits for a BOSH deployment) to the BOSH server.

For a good introduciton on the initial goals of the project (back in 2015), see the Introducing bosh-workspace: how we deploy all things BOSH video.


Getting started

Before you start make sure ruby, bundler and spiff are available on your system. Instructions for installing spiff can found here.

Creating a workspace repository

First you will have to create a new repo for our company called Foo Group (short FG).

git init fg-boshworkspace
cd fg-boshworkspace

Lets create the initial files & directories.

mkdir deployments templates
echo -e 'source ""\n\ngem "bosh-workspace"' > Gemfile
echo "2.1.0" > .ruby-version
echo -e '.stemcells*\n.deployments*\n.releases*\n.stubs*\n' > .gitignore

Now install the gems by running bundler.

bundle install

Lets finish by making an initial commit.

git add .
git commit -m "Initial commit"

Creating a first deployment

For demonstration purposes we will deploy Cloud Foundry on bosh-lite. The steps below will show the bosh-workspace equivalent of bosh-lite manual deploy instructions.

Before we start make sure you have access to properly installed bosh-lite.

We will start by targetting our bosh-lite.

bosh target
bosh login admin admin

Now lets create our deployment file.

cat >deployments/cf-warden.yml <<EOL
name: cf-warden
director_uuid: current

  - name: cf
    version: latest

  - name: bosh-warden-boshlite-ubuntu-lucid-go_agent
    version: 60

  - cf/cf-deployment.yml
  - cf/cf-jobs.yml
  - cf/cf-properties.yml
  - cf/cf-resource-pools.yml
  - cf/cf-infrastructure-warden.yml
  - cf/cf-minimal-dev.yml

      memory_limit: 102400 # Increased limit for demonstration purposes

Now lets use this deployment and upload it's dependencies.

bosh deployment cf-warden
bosh prepare deployment

Lets make sure to above template paths exist.

ln -s ../.releases/cf/templates templates/cf

To finish we only have to start the deployment process and commit our changes.

bosh deploy
git add . && git commit -m "Added cf-warden deployment"

Congratulations you should now have a running Cloud Foundry. For further reference on how to start using it go to the bosh-lite documentation.

Managing sandbox and production environments

The suggested way of doing this is to create many similar deployments in the deployments/ folder. They typically have tha same radix like cf or mysql as prefix of their name, and be distinguished by a -sandbox.yml suffix or -prod.yml depending on your environments names.

Then each of those similar deployment can express variants by including environment-specific Spiff stubs, or specifying specific configuration in the meta root YAML node. Easy as that. Examples of deployment variants can be found in cf-boshworkspace.

Using private boshreleases

When using a boshrelease from a location which requires authentication a .credentials.yml file is required, located at the root of your boshworkspace. Two types of authentication are supported: username/password and sshkey.

Example .credentials.yml file:

- url:
  username: foo
  password: bar
- url: ssh://
  private_key: |

Install Notes


cmake isneeded and libssh2 is optionally (only needed when using cloning over ssh)

brew install cmake libssh2 pkg-config


cmake and libcurl4-openssl-dev is needed for rugged install

sudo apt-get install cmake libcurl4-openssl-dev libssh2-1-dev


dns support

Dns support can be enabled by adding a domain_name property to your deployment. For example: domain_name: microbosh or if you are using a normal bosh just use bosh. When enabled, a transformation step will be executed after the spiff merge. Which will transform all the static ip references into domain names.


  1. Fork it
  5. Create new Pull Request

List of Contributors

You can’t perform that action at this time.