Central Deployer Pattern

Kubes can be use as either an app-centric or ops-centric tool.

  • app-centric: Each app repo has it’s own .kubes settings files. This is useful if your applications are very differently setup.
  • ops-centric: Each app repo has pretty much the same .kubes settings files. This is useful if your applications are very similarly set up.


With an ops-centric approach, you use the same .kubes settings files for the app repos you want to use. For example:


You then also have a


You can simply copy the .kubes folder into the app repo folder or even add the repo/.kubes as a submodule.

You’ll end up with something like this:


Then to deploy different app level settings.

App-Level Specific Settings

You can override all the different settings at the app-level when KUBES_APP is set.

For app1:

cd app1
KUBES_APP=app1 kubes deploy

And for app2:

cd app2
KUBES_APP=app2 kubes deploy

Config Env

Override config/app.rb with app-level settings like so:



Override .kubes/variables/base.rb, .kubes/variables/dev.rb etc like so:



Override resources like so:


Also check out: App Overrides Docs.

The central deployer approach is removes duplication of the kubes config files between projects. Leveraging app-level overrides gives provides a great degree of control.

If the settings start to diverge too much, then it probably makes sense to use separate .kubes files in that app specific repo.