Bootstrap an SKE platform with kubara

Zuletzt aktualisiert am 15. Sept. 2026

kubara is an open source project that offers a single-binary CLI for building, packaging, and bootstrapping Kubernetes platforms. With kubara, you get everything except your Git repository right out of the box.

kubara bundles a GitOps engine and multiple Helm charts into a so-called catalog and helps you deploy this stack of applications on your Kubernetes cluster, enabling you to quickly start developing or operating applications.

A kubara catalog can bundle Helm charts, Terraform modules, scripts, and the GitOps structure needed for a platform. kubara renders that catalog into reproducible artifacts and bootstraps the initial Argo CD setup.

kubara is not an operator. It does not install its own kubara controller or any other kubara runtime components in your cluster. After bootstrap, Argo CD reconciles the generated platform state from Git.

It is actively developed and available on GitHub. More information can be found in the official documentation.

If you want to try out kubara locally, you can use it in local mode for evaluation. See the quick start guide.

kubara has integrated providers such as STACKIT that let you start from a green field (an empty project) and provide a Terraform/OpenTofu deployment to start from scratch. You only need a Git repository. For this use case, you can skip to the provider deployment section.

If you want to deploy kubara on Google Cloud, there is also a dedicated guide.

If you have a use case that requires existing infrastructure, such as an existing Kubernetes cluster, DNS service, and so on, you will find an introduction on how to run kubara with your setup below.

To run kubara in the cloud you need the following components:

a Git repository (for example STACKIT Git, Codeberg, GitHub, etc.)
a Kubernetes cluster
a DNS zone for external-dns (example-zone.your-domain.com)
an external-secrets-compatible secrets manager
the necessary secrets (you can find an example on how to create them below)
IAM permissions
(optional but recommended) an object storage bucket for your IaC state (Terraform or OpenTofu)
(optional) an object storage bucket for Velero

For STACKIT, kubara can generate a provider deployment that uses platform-native services:

If you want to use other external services, such as Cloudflare for DNS or Bitwarden for secrets, you can proceed with an individual configuration.

Provider deployment

If you want a green-field deployment of kubara on STACKIT, follow kubara’s own installation guide. This generates a Terraform/OpenTofu deployment that contains everything necessary to set up a platform. You need STACKIT Git or any other Git provider you prefer.

If you want to use your existing infrastructure, such as an existing STACKIT Secrets Manager or another component, you have to configure some things yourself. In this case, choose the individual configuration and adapt it to your needs.

Individual configuration

Because your needs might be highly individual, we start with a list of the infrastructure that kubara depends on. This is the advanced option, and it requires getting familiar with the configuration of each component.

Prerequisites

A Git repository (for example, Codeberg or GitHub)
A Kubernetes cluster (your kubeconfig)
A DNS zone for external-dns (example-zone.your-domain.com)
An external-secrets-compatible secrets manager
The necessary secrets (listed below)
IAM service permissions
(optional) An object storage bucket for Velero

Process overview

Since you want to deploy to an existing SKE cluster, we assume in this example that you already have an SKE cluster and a valid kubeconfig.
Configure your external-dns according to your provider, for example STACKIT DNS or Cloudflare.
Adapt your external-secrets operator configuration according to the secrets store you want to use (for example, STACKIT Secrets Manager or OpenBao). Read how to prepare external-secrets credentials on the spoke cluster in the kubara docs.
Create the necessary secrets.
Create service accounts on the corresponding platforms (object storage, DNS API, and so on). This step is listed so that you can make sure you have configured permissions for all the services you need.
Create your cluster secret store — see the ClusterSecretStore docs.
(optional but recommended) Make sure you have configured your OAuth2 provider. Some provider examples (GitHub, STACKIT Git) can be found in the kubara docs.
(optional) Create the Velero backup bucket.

You’ll need to adapt the following Helm values with your secret names:

platform-configs/<my-cluster>/helm/argo-cd/values.yaml
platform-configs/<my-cluster>/helm/external-dns/values.yaml
platform-configs/<my-cluster>/helm/external-secrets/values.yaml
platform-configs/<my-cluster>/helm/kube-prometheus-stack/values.yaml
platform-configs/<my-cluster>/helm/oauth2-proxy/values.yaml

You’ll also need to create the following secrets:

cluster-secrets-docker-config
argocd-argo-oauth2-credentials
oauth2-proxy-oauth2-credentials
kube-prometheus-stack-grafana-credentials
kube-prometheus-stack-grafana-oauth2-credentials

Creating the necessary secrets

Since you are not using the Terraform bootstrap, you have to create the secrets manually.

Some secrets need a certain format (for example, Base64 encoding, or the OAuth2 Proxy cookie secret). The following steps describe how to create them.

After creating the secrets, you have to save them in your secrets store, which depends on the secrets manager you use. Visit the STACKIT Secrets Manager docs to learn how to view, create, and delete secrets.

You are free to choose the names of your secrets, as long as you reference them correctly in your values file. However, we highly recommend a fixed schema like:

<clustername>-<stage>-<secretname>

… which means that, for a DEV-stage cluster named kuby, the Docker pull secret would be called:

kuby-dev-cluster-secrets-docker-config

# Decode the base64-encoded Docker pull secret and store it as the JSON field "pull-secret" in your Secrets Manager
printf '%s' '$YOUR_PASSWORD_IN_BASE64' | base64 -d | jq -Rs '{"pull-secret":.}'

# Replace "$YOUR_PASSWORD" with your desired Grafana admin account password.
printf '%s' '{"admin-user":"admin","admin-password":"$YOUR_PASSWORD"}'

# Replace secret values according to your SSO App Client ID and Secret
printf '%s' '{"client-id":"$YOUR_GRAFANA_CLIENT_ID","client-secret":"$YOUR_SECRET"}'

# Generate the cookie secret locally
dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_' ; echo

# Replace secret values accordingly
printf '%s' '{"client-id":"$YOUR_OAUTH2_CLIENT_ID","client-secret":"$YOUR_SECRET","cookie-secret":"$YOUR_COOKIE_SECRET_CREATED_ABOVE"}'

Based on the OAuth2 Proxy Docs - Generating a Cookie Secret.

# Replace the secret name according to your cluster name and stage (for example "gcp-dev"), and replace the secret values accordingly
printf '%s' '{"client-id":"$YOUR_ARGO_CLIENT_ID","client-secret":"$YOUR_SECRET"}'

After saving your secrets to your secrets manager, you have to change the values in the values.yaml files according to the names you defined when creating them.

Completing the process

Make sure to tick all the items in the checklist below before proceeding:

Have your kubeconfig ready, so kubara can deploy manifests and Helm charts.
Verify that you have created all necessary secrets.
Verify that you have prepared the ClusterSecretStore manifest, so it is ready to be deployed.
Verify that you have changed all secrets in the values.yaml files of the Helm charts, so the applications will find and use your secrets.
Make sure to merge all your changes to Git, so that Argo CD can deploy.

From there, you can follow the official documentation.

# Your invocation of kubara bootstrap will look similar to this:
kubara bootstrap <cluster-name-from-config-yaml> \
  --kubeconfig your-kubeconfig.yaml \
  --with-es-css-file clustersecretstore.yaml

Feel free to contribute or suggest changes to the project. Open source thrives on participation and contribution. The project lives on GitHub — you can find the repository here.