Re: Best practices on bosh release distribution

Dmitriy Kalinin

Typically releases are distributed to end users via release tarballs or
release git repo:

- to generate release tarball use `bosh create release --with-tarball` or
for the existing release `bosh create release
releases/some-release/some-release-7.yml --with-tarball`; users then upload
release to the Director via `bosh upload release some-release-7.tgz`
- alternatively, you can tell users to checkout git repo and run `bosh
upload release releases/some-release/some-release-7.yml`

On Fri, Jun 5, 2015 at 8:45 AM, Gwenn Etourneau <getourneau(a)>

If you OpenSource your bosh-release you can ask to be added to and you will be able to ask
for the community s3 bucket to put your final release and maybe be added to
the website.

Or/and you can create a tarball of the full release and distribute this
tarball and of course the documentation for the bosh deployment manifest.

create release [<manifest_file>] [--force] [--final] [--with-tarball]
[--dry-run] [--name NAME] [--version VERSION]
Create release (assumes current directory to be a release repository)
--force bypass git dirty state check
--final create final release
* --with-tarball* create release tarball
--dry-run stop before writing release
--name NAME specify a custom release name
--version VERSION specify a custom version number
(ex: 1.0.0 or 1.0-beta.2+dev.10)

On Sat, Jun 6, 2015 at 12:12 AM, Sumanth Yamala <Sumanth.Yamala(a)>


I have a process which creates a bosh release -> which has all the
artifacts and use a microbosh instance to create my release. It all works
great! As I move to the next step to distribute my releases to cross
departments and external customers – what are the best practices around
this? How do we distribute bosh releases?



cf-bosh mailing list

cf-bosh mailing list

Join { to automatically receive all group messages.