What Is Sugarkube?

Sugarkube is both an orchestrator and software release system targetting Kubernetes clusters. It allows you to create and destroy ephemeral clusters. Code for your applications can contain configs for creating infrastructure allowing you to version them together as a single unit. This means the releasable artefact is your application code and the code to create the infrastructure it needs. If you embrace ephemeral clusters, the deliverable unit really becomes the entire cluster itself.

Many other tools only create either infrastructure (Kubernetes, Terraform, CloudFormation, etc.) or release your applications (Helm, tarballs, whatever). This means you need some way of coordinating your application changes with the infrastructure they depend on, which can be complicated and error-prone. You also need a way of preparing a cloud account first, e.g. to create DNS zones, S3 buckets, VPNs, etc.

After defining which of your applications depend on which others Sugarkube constructs a dependency graph which allows it to install or delete your applications in the correct order. So, for example, if your Wordpress sites depend on databases and a load balancer, Sugarkube can make sure they’re created before the Wordpress sites are installed, and deleted after the Wordpress sites have been deleted when tearing down the cluster. Sugarkube can also pass the hostnames of the databases to the Wordpress sites. Here’s what the dependencies might look like:

Wordpress Dependencies

This is actually the dependency graph for our example web cluster. You can see how easy it is to run for yourself by following our tutorials.

App code & infra code versioned together

Versioning your applications and infrastructure together is incredibly powerful. This idea means Sugarkube can:

  • Recreate your clusters at any point in time (minus data of course). Therefore Sugarkube allows you to easily create short-lived ephemeral clusters on demand. This ability alone – which is entirely optional – opens up some very powerful capabilities
  • Support multi-cloud - A kapp can create one set of infrastructure when being installed into AWS and a different set when being installed into GCP/Azure, on-premise or even locally. Just write the appropriate scripts/Terraform configs and Sugarkube will run the correct ones depending on your target cloud.
  • Manage exactly which versions of your kapps get released into each of your environments.
  • Truly promote your applications and infrastructure through environments. An emphasise on portable artefacts (kapps) prevents you creating brittle snowflake environments.
  • Install “slices” of your stack into different environments. For example if you have several monitoring and metric collection applications installed alongside your web sites, you can choose not to install the monitoring stack in your dev environment if you’re not going to work on it.

All of the above make it simple to start working on new features without wasting time recreating infrastructure that your applications need. Adopting Sugarkube for a project will also lay extensive foundations for future scaling, both technologically and for when your team grows.


A key feature that makes Sugarkube so flexible is that it allows you to parameterise your deployments differently depending on the target cloud account or purpose of the cluster. So for example you can easily configure Sugarkube to use lots of large instances for your cluster in production, but only a few smaller ones for dev environments. Or you could create a small database and install fixture data into it in dev environments while using your real database in production.

If you want to you can define your configuration hierarchically. This means you could create default configurations and progressively override or replace certain parts at more specific levels. To give a concrete example, a directory structure such as below would allow you to override and tailor your configurations in several ways:

- providers
  - aws
    - dev
      - kops.yaml        # extra config just for kops clusters
      - dev1.yaml        # configs just for the 'dev1' cluster
      - eu-west-1.yaml   # configs for all dev clusters in eu-west-1
    - test
      - kops.yaml        # extra config just for test kops clusters
    kops.yaml            # default kops config

Sugarkube will search for files with various basenames at each level in your directory hierarchy, merging them together depending on the parameters of your target cluster. In addition, values in these config files can contain variables. Some practical applications of this are:

  • Easily configure using a few, small instances for your cluster in dev/test environments while using more, larger instances in staging and production.
  • Easily set default, region-specific base image IDs.
  • Apply naming conventions to fully namespace all your resources - e.g. create DNS zones per cluster called {{cluster}}.{{region}}.example.com

Cluster types/cloud providers are details

Sugarkube has been designed to for maximum portability. It should be pretty seamless to develop on a local Minikube cluster and then deploy onto a cloud-based/hosted cluster. With a bit more effort it becomes possible to migrate applications between cloud providers as well allowing you to run in a multi-cloud setup.

Extra features for Kubernetes users

If you work with Kubernetes clusters Sugarkube provides additional features. As already mentioned, it can launch Kubernetes clusters and can do so with several provisioners (for now EKS, Kops and Minikube) and then configure them. For example it can patch Kops YAML configs before triggering an update to apply those changes. This makes it a useful tool for administering long-lived Kubernetes clusters when ephemeral clusters aren’t an option. However its main benefit is that it allows you to create a cluster and install your applications (with dependent infrastructure) with almost a single command.

Although technically you don’t have to use Kubernetes, Helm and Terraform with Sugarkube, for the sake of simplicity we’ve made an assumption that you will be, at least for now. This allows us to simplify the problem-space and get something working in a more predictable setup instead of trying to please everyone immediately. So if you choose not to use K8s, Helm and Terraform you may find a few things don’t work as expected. Please open an issue on Github to tell us about those scenarios if you run into them so we can track them.

Choose your own tools

As an orchestrator Sugarkube wraps other tools you’re probably already familiar with. It delegates to eksctl/kops/minikube for provisioning clusters, and our sample project and default configuration file assume Helm and Terraform. However you aren’t forced to use any particular set of tools or technologies. Sugarkube will work with on-premise, legacy systems and infrastructure provided it’s scriptable, and also with any programming language. You can adopt it bit-by-bit while you get used to it, and migrate more to it (or drop it) as you wish.