Create a local kind cluster, generate reviewable platform state with kubara, and let Argo CD reconcile it through a complete GitOps workflow.

TL;DR: This tutorial uses kubara to create a local Kubernetes platform on kind, bootstrap Argo CD, configure a local OpenBao secret backend, and expose platform services through cloud-provider-kind. You will inspect the platform contract, commit the generated desired state to Git, and observe how Argo CD reconciles it. The setup mirrors the core operating model of a production GitOps platform, but it deliberately uses local and development-oriented components that are not suitable for production.

Reading about a GitOps platform is useful. Watching the complete handoff from a declarative platform configuration to a reconciled Kubernetes cluster is even better.

In this tutorial, kubara creates a local kind cluster, bootstraps Argo CD, starts OpenBao as a development secret backend, and exposes platform services through cloud-provider-kind. Within approximately 10–15 minutes, you can inspect the platform contract, explore the generated repository structure, and observe the resulting GitOps state on your own machine.

This setup is not a production blueprint. It is a focused learning and development environment that reproduces the core operating model of a production GitOps platform: kubara translates platform intent into reviewable desired state, Git stores the approved configuration, and Argo CD continuously reconciles it. The local infrastructure deliberately prioritizes accessibility and speed over production-grade security, resilience, and availability.

What You Need

Install the following tools before you begin:

• kubara
• a container runtime such as Docker, Podman, or Colima
• Helm
• kind
• cloud-provider-kind as a host binary
• kubectl
• Git

You also need permission to run cloud-provider-kind with elevated privileges and an empty Git repository for the generated desired state. A public test repository is the simplest option for this evaluation. When using a private repository, you must provide credentials that allow Argo CD to clone it.

Install kubara with Homebrew:

brew tap kubara-io/tap
brew trust kubara-io/tap
brew install kubara
kubara --help

Alternatively, use the installation script documented by the project:

curl -sSLf https://raw.githubusercontent.com/kubara-io/kubara/refs/heads/main/install.sh | sh
kubara --help

Create or clone the Git repository you want Argo CD to use, and run all remaining commands from its root directory.

Step 1: Prepare the Local Environment

Start by generating the files required for the local workflow:

kubara init --prep --local

This creates a local .env template and updates .gitignore. Open .env and configure the Git repository URL, the local evaluation password, and—when required—the credentials for a private repository.

Important: Never commit .env or any repository credentials to Git.

At this point, kubara knows where the generated desired state will be stored and how Argo CD should access it.

Step 2: Generate config.yaml

Create the local platform configuration:

kubara init --local

Before continuing, open config.yaml and inspect the generated cluster profile, platform services, and service-specific configuration. This file represents the declared platform intent that kubara will translate into concrete, reviewable state.

Do not treat config.yaml as just another installation file. It is the starting point of the workflow you are evaluating:

platform intent → generated state → Git review → Argo CD reconciliation

Step 3: Bootstrap the Local Cluster

Bootstrap the local platform on a kind cluster named test-cluster:

kubara bootstrap --local test-cluster

When kubara prompts you to start the local load-balancer integration, open a second terminal and run:

sudo cloud-provider-kind

Keep this process running while you use the local environment.

During the bootstrap, kubara creates the kind cluster, installs the required namespaces and CRDs, bootstraps Argo CD, prepares the local OpenBao development setup, and waits for the load-balancer address.

After the bootstrap completes successfully, kubara prints the next steps and the locally generated access information. The exact addresses and credentials depend on your environment, but the output should resemble the following:

🎉 Local kubara bootstrap complete!

📝 Next steps:
1. Commit and push all repository contents generated by kubara.
2. Ensure the Git repository is reachable by Argo CD.
   If you did not provide both ARGOCD_GIT_USERNAME and ARGOCD_GIT_PAT_OR_PASSWORD, ensure the Git repository is public so Argo CD can pull it.

Argo CD should be reachable in a couple of minutes via:
    https://<your-lb-ip>.traefik.me/argocd

You can otherwise immediately access the Argo CD UI via:
    kubectl --kubeconfig .local/kind.kubeconfig port-forward svc/argocd-server -n argocd 8080:443
    then open http://localhost:8080/argocd in your browser

Log in with:
    wizard / xxxx

Other useful links:
  - Portal:  https://<your-lb-ip>.traefik.me
  - OpenBao: https://openbao.<your-lb-ip>.traefik.me/ui login with root

Copy the credentials printed by your own bootstrap command. Do not publish or reuse credentials copied from another environment.

Step 4: Commit, Push, and Observe

A successful bootstrap creates the local cluster and its initial platform state, but Git becomes the source of truth only after the generated files have been reviewed, committed, and pushed.

Start by inspecting the repository:

git status
git diff

Make sure that .env and the contents of .local/ are not included in the commit. Then commit the platform contract and generated desired state, and push them to the repository configured in .env.

The main repository areas have different responsibilities:

Once the commit is available remotely, Argo CD can retrieve the desired state and begin reconciling the generated Applications.

Use the generated kubeconfig to inspect the cluster:

kubectl --kubeconfig .local/kind.kubeconfig get pods -A
kubectl --kubeconfig .local/kind.kubeconfig get ingress -A
kubectl --kubeconfig .local/kind.kubeconfig get applications -n argocd

The Applications should eventually report both Healthy and Synced. Some components may take a few minutes to become ready, especially while container images are being downloaded or load-balancer addresses are being assigned.

If the ingress endpoint is not yet available, create a direct local connection to the Argo CD API server:

kubectl --kubeconfig .local/kind.kubeconfig \
  port-forward svc/argocd-server -n argocd 8080:443

Then open:

http://localhost:8080/argocd 

#or

https://<your-lb-ip>.traefik.me/argocd

Sign in with the credentials generated for your local environment.

The dashboard is useful, but it should not be the only success criterion. A meaningful evaluation should help you answer the following questions:

• Which platform services are enabled in config.yaml?
• What did kubara generate under platform-components/ and platform-configs/test-cluster/?
• Can Argo CD access the configured Git repository?
• Are the generated Applications both healthy and synchronized?
• Which files are owned by kubara, and where should long-lived customizations be placed?
• What happens after the platform contract changes and the generated state is updated?

These questions reveal the actual operating model: kubara translates declared platform intent into transparent and reviewable desired state, while Argo CD continuously reconciles the approved state from Git.

Why This Setup Is Not for Production

At this point, the local environment demonstrates the kubara operating model. It does not demonstrate production readiness.

The --local workflow deliberately prioritizes accessibility and speed over resilience, security, and availability. OpenBao runs in development mode with temporary state and evaluation credentials. Restarting the environment may remove local secret data, and a development root token must never be used in a real platform.

A production environment requires explicit architectural decisions around:

• identity and access management
• secret storage and credential rotation
• networking and DNS
• certificate management
• persistent storage
• high availability
• backup and recovery
• repository access
• monitoring and operational ownership

The local preset mirrors the GitOps operating model, not the production architecture. It is a safe environment for learning how the platform contract, generated state, Git repository, and Argo CD reconciliation work together — not a shortcut around production engineering.

Try One Day-2 Change

Before deleting the cluster, make one small change to a service configuration in config.yaml — for example, adjust a value of one of the enabled platform services.

Then regenerate the platform state:

kubara generate --helm

Inspect the resulting Git diff before committing anything:

git diff

The important sequence is:

change the contract → regenerate → inspect the diff → commit and push → observe reconciliation

After pushing the update, watch the affected Application in Argo CD and verify that it returns to Healthy and Synced.

This experiment demonstrates one of the most important characteristics of kubara: it is not useful only during the initial bootstrap. It remains the controlled translation layer for Day-2 platform changes, allowing teams to review and promote platform updates through Git instead of modifying clusters manually.

Clean Up the Local Environment

When you have finished the evaluation, delete the kind cluster:

kind delete cluster --name test-cluster

Stop the cloud-provider-kind process in the second terminal with Ctrl+C.

You can keep the Git repository if you want to inspect the generated structure later or use it as a reference for another local experiment. Local files under .local/ can be removed because they contain environment-specific bootstrap state rather than durable platform configuration.

From Local Evaluation to a Real Platform

The most valuable part of this local setup is that it introduces the same core workflow used by larger kubara-managed environments:

• the platform is declared through a contract
• reusable capabilities come from a catalog
• kubara generates platform components and cluster-specific configuration
• changes are reviewed and promoted through Git
• Argo CD remains the continuous reconciliation engine
• ApplicationSets can target clusters through labels

Moving beyond the local preset does not mean promoting the kind cluster itself to production. Instead, it means applying the same operating model to a properly designed Kubernetes environment with production-grade identity, secrets, networking, storage, availability, and recovery.

A sensible next step is to use the official kubara documentation to model a non-production hub on an existing Kubernetes cluster. From there, you can gradually introduce additional clusters, environment-specific configuration, external secret backends, and controlled delivery boundaries.

Your Support for Open Source ❤

kubara is an open-source project, and it will continue to evolve through practical use, feedback, and contributions from the community. If the approach described in this article resonates with you, take a look at the project, try it with one of your existing Kubernetes clusters, and let us know what you think.

And if you find the idea useful, consider leaving kubara a ⭐ on GitHub. It is a small gesture, but it helps more platform engineers discover the project and lets us know that we are building something worth continuing.