Page last updated:
This topic provides resources for creating a BOSH release that integrates a software service with Pivotal Platform at the managed service level.
A BOSH release is a directory that contains the source code for your service along with everything else that BOSH needs to deploy it reproducibly to cloud VMs running a specified operating system (stemcell). These contents include but are not limited to buildpacks, start up scripts, binary artifacts, and a BOSH manifest containing configuration and deployment properties.
The BOSH manifest specifies the following major components:
Packages that can be installed on Pivotal Platform stemcells to create VM images
Jobs that describe how to install, run, and remove your software
A Monitor script, that describes how to monitor the health of your service components and stop or restart them
These topics give more details on BOSH and BOSH releases:
BOSH Documentation is the top-level contents page for BOSH documentation.
BOSH Problem Statement explains what BOSH does.
BOSH Basic Workflow lists the high-level steps for creating a BOSH deployment.
These topics explain how to create a BOSH release:
If you have already packaged your service as Docker images, you can emulate
a managed service deployment using the Tile Generator’s
docker-bosh packages. This feature lets you deploy pre-existing
Docker images into BOSH-managed VMs on the Pivotal Platform infrastructure.
While this is a great, easy way to deploy your service on Pivotal Platform, we do not recommend this as a long-term, production-ready solution. There is really no benefit of running your service in containers on the VMs, and it does have a number of operational (“day 2”) drawbacks:
You introduce more software (Docker) which needs to be kept up-to-date, and has the potential for issues, downtime, and security vulnerabilities.
You can no longer take advantage of the patching capabilities of Pivotal Platform for stemcells and application dependencies, such as frameworks and libraries. Instead, you become directly responsible for managing all software that is in the Docker images you deploy.
After the basic BOSH release is in place, additional features for logging
help operators run the service. For logging information, see
Pivotal recommends you expose the property
syslog.migration.disabled using the
tile’s forms because not all customers configure syslog draining.
Logs written under the expected BOSH location
/var/vcap/sys/log are forwarded
to the configured syslog server by the release.
Integrating syslog forwarding into a tile should not require code changes;
it only requires including the release and configuration forms in the
For an example, see pcf-examples/tile-for-bosh-with-syslog.
The BOSH Backup and Restore Developer’s Guide describes the framework for release authors to add backup and restore functionality to their release by using BOSH Backup and Restore (BBR).