Automating your workflow

Learn best practices around managing your releases in version control to enable collaboration and automation.

Now that you’ve made some releases using the UI in, its time to check your yaml into source control and start collaborating with your team. We’ll use the Replicated Kubernetes Starter as a starting point for this.


This guide assumes you’ve already completed the steps in create-release and install. If you haven’t already, you should complete those guide sections first. You’ll also need:

  • node
  • make
  • A git repository created to manage your Replicated YAML. We’ll use github in this example.

Get started

First, clone the starter repo, and re-initialize it

git clone
cd replicated-starter-kubernetes
rm -rf .git
git init
git remote add origin <your git repo>

Configure Environment

You’ll need to set up two environment variables to interact with, REPLICATED_APP and REPLICATED_API_TOKEN. REPLICATED_APP should be set to the app name in the URL path at

Next, create an API token from the Teams and Tokens page:

Ensure the token has “Write” access or you’ll be unable create new releases. Once you have the values, set them in your environment.


You can ensure this is working with

make deps list-releases

Iterating on Releases

Once you’ve made changes to replicated.yaml, you can push a new release to a channel with

make release channel=Unstable

For an integrated development approach, you can use make watch to watch the replicated.yaml file, linting and releasing whenever changes are made.

make watch channel=my-dev-channel

CLI with Docker

Use replicated/vendor-cli Docker image to execute the CLI inside a container. This is useful in environments where make and replicated vendor CLI are unsupported, such as Windows OS.

The example below shows replicated vendor cli help, this can be used as a scaffold to build other commands.

docker run \
  replicated/vendor-cli --help

Run the following to list releases and verify Docker vendor CLI works.

make docker-list-releases

Push new release to a channel with Docker vendor CLI.

make docker-release channel=Unstable working_dir=/path/to/git/repo

Operating Systems Compatibility

On Windows OS ensure the working_dir is shared and available in Docker (Settings -> Shared Drives).

Integrating with CI

Often teams will use one channel per developer, and then keep the master branch of this repo in sync with their Unstable branch.

The project includes CI configs for Travis CI, CircleCI, Jenkins CI and GitLab CI.

The configs will:

On pull requests:

  • Install dependencies
  • Lint yaml for syntax and logic errors

On merges to the github master branch:

  • Install dependencies
  • Lint yaml for syntax and logic errors
  • Create a new release on the Unstable channel in Replicated

These behaviors are documented and demonstrated in the replicated-ci-demo project.