How kubara combines a declarative platform contract, a curated component catalog, and Argo CD to generate reusable and reviewable platform state.
TL;DR: kubara is an open-source CLI for defining and evolving Kubernetes platforms through a GitOps-first workflow. It combines a declarative platform contract with a curated component catalog and generates reviewable configuration that can be committed to Git. kubara bootstraps the desired state, while Argo CD continuously reconciles it. It is not a Kubernetes distribution, a developer portal, or a replacement for Argo CD. kubara received some updates, so we wanted to present its new features and the problems it solves without altering the existing blog posts.
A Kubernetes cluster is not yet a platform.
Kubernetes can schedule workloads, expose services, and provide APIs, but application teams usually need much more: ingress, certificates, DNS, secrets, policies, observability, storage, backups, and a reliable delivery process. Installing these capabilities is rarely the hardest part. The real challenge is combining them into a coherent platform that can be reproduced, reviewed, upgraded, and operated consistently across different clusters and environments.
That is the problem kubara is designed to address.
kubara is an open-source CLI that combines a declarative platform contract with a curated component catalog and generates reviewable GitOps state. It provides an opinionated starting point without hiding the resulting configuration: platform teams can inspect, test, commit, and promote the generated state through Git. kubara handles generation and bootstrap, while Argo CD continuously reconciles the approved state against the target clusters.
Why Platform Teams Need More Than a Collection of Helm Charts
Platform teams often face three connected challenges:
- Missing expertise and costly iterations: Teams should not have to repeat the same evaluation and integration work before they can build a usable platform.
- A complex Kubernetes ecosystem: Choosing the right tools is only the beginning. Their APIs, dependencies, configuration, and lifecycles must also work together.
- Continuous change: Kubernetes and its surrounding ecosystem evolve quickly. Platform updates need to be tested, reviewed, and promoted without turning every upgrade into a platform redesign.
kubara addresses these challenges through a maintained catalog of curated component definitions and versions, reproducible generation, and a GitOps operating model. It does not replace engineering judgment. Instead, it gives platform engineers a coherent baseline from which they can make deliberate decisions.
To understand how kubara turns this baseline into an operational workflow, it helps to look at the three elements at the center of its model: the platform contract, the catalog, and GitOps.
The Core Model: Contract, Catalog, and GitOps
The most important kubara concepts can be summarized in four steps.
1. Declare the platform contract
Platform engineers describe the intended platform in config.yaml, including clusters, stages, providers, enabled services, and service-specific configuration. This file acts as the machine-readable contract between the platform team and the kubara CLI.
2. Combine it with a platform catalog
kubara includes an embedded built-in catalog containing platform definitions and curated component versions. Users do not modify this catalog directly. Organizations that need additional or alternative definitions can provide an external catalog, which kubara merges with the built-in catalog to produce one effective catalog.
The package-manager analogy is useful here: a Helm chart packages an application, whereas a kubara catalog packages the definitions and configuration patterns for a reusable platform architecture. However, kubara does more than manage the catalog. It also generates the desired platform state and prepares it for GitOps-based delivery.
3. Generate reviewable platform state
kubara combines the platform contract and the effective catalog to generate concrete artifacts. The two main output areas are:
platform-components/for reusable generated componentsplatform-configs/for cluster-specific values and configuration
The generated files can be inspected, tested, versioned, and reviewed like any other code. Long-lived customizations should be placed in documented override files rather than made directly in kubara-generated files.
4. Let Argo CD reconcile the result
kubara bootstraps Argo CD on the hub cluster. Once the generated desired state has been reviewed, committed, and pushed, Argo CD continuously reconciles it against the target clusters.
This responsibility boundary is important: kubara generates and bootstraps the platform state, while Argo CD handles continuous reconciliation. kubara therefore does not need to run as a permanent controller in each cluster.
The catalog is what makes this workflow reusable across clusters and environments. It provides the shared foundation that organizations can adopt, extend, and configure for their own platform requirements.
The Built-In Catalog
The built-in catalog provides a default platform baseline. Its definitions and templates are embedded in kubara and are not edited directly by users. Organizations can extend or adapt this baseline through an external catalog, which kubara merges with the built-in catalog to create the effective catalog. Components exposed by this effective catalog can be enabled and configured per cluster, so the catalog describes available capabilities rather than a fixed set of services that must be installed everywhere.
What are components?
Components are the building blocks that turn a Kubernetes cluster into an operational platform. Kubernetes provides workload orchestration, while platform components add capabilities such as GitOps delivery, ingress, DNS, certificate management, secret synchronization, policy enforcement, observability, authentication, storage, and backup. kubara packages curated component definitions and their configuration patterns so that platform engineers can start from a coherent baseline instead of integrating every tool independently.
The required combination depends on the target environment. A managed Kubernetes service may already provide load balancing, persistent storage, a managed control plane, and other infrastructure integrations. In that case, kubara can add platform capabilities such as Argo CD, External Secrets Operator, cert-manager, Kyverno, and observability while leaving provider-managed services in place. Edge or bare-metal environments may additionally require components such as MetalLB for LoadBalancer Services or Longhorn for distributed storage. Some storage solutions also require operating-system-level preparation and must be evaluated against the selected Kubernetes distribution.
kubara is therefore designed to support managed Kubernetes, existing clusters, hybrid environments, and edge deployments without assuming that the same component set fits every environment. Platform engineers select the components that complement the capabilities already provided by the target cluster.
The following figure presents the components available in kubara's built-in catalog. It should be read as a toolbox rather than a fixed installation blueprint. The accompanying table groups the components by platform capability and explains the responsibility each group adds on top of Kubernetes.
The built-in catalog defines which platform capabilities are available. The next question is where those capabilities are applied as the platform grows from a single cluster into a multi-cluster environment.
From a Single Cluster to Hub and Spokes
kubara supports a central hub-and-spoke architecture in which the hub acts as the management cluster. Argo CD runs on the hub and manages the desired platform state on both the hub itself and any registered spoke clusters. Spokes can provide separate Kubernetes boundaries for environments, regions, teams, tenants, or workload groups, depending on the organization's isolation requirements.
Teams do not need to begin with a large cluster fleet. A single Kubernetes cluster is a valid starting point and can serve as both the initial platform and management cluster. As additional environments or isolation boundaries are needed, spoke clusters can be registered and managed through the same platform contract, catalog, and GitOps workflow.
This architecture provides the foundation. The next question is how kubara turns it into an operational workflow that can be bootstrapped, evolved, and extended across clusters.
Core Capabilities of kubara
The hub-and-spoke architecture describes where the platform state is managed. In practice, kubara supports the complete workflow around that state: bootstrapping the initial platform, evolving it through Day-2 changes, onboarding additional clusters, and defining controlled GitOps delivery boundaries.
Core Capability 1: Bootstrap and Evolve the Platform
kubara can bootstrap a platform on an existing Kubernetes cluster. The initial hub hosts Argo CD and manages its own desired state, while additional spoke clusters can be registered later. Optional Terraform presets can help provision selected infrastructure, but they are not required to onboard either a hub or a spoke.
Bootstrap is only the beginning. When the platform contract, configuration, or catalog version changes, kubara regenerates the desired state. Platform engineers can review the resulting Git diff, test the changes, and promote them through the normal Git workflow. Argo CD then reconciles the approved state against the target clusters.
This makes the same workflow useful for both initial platform creation and controlled Day-2 operations.
Core Capability 2: Onboard and Target Spoke Clusters
A spoke cluster must already exist and be reachable from the hub. Its access credentials should be stored in the configured secret backend rather than committed to Git. Platform engineers then add the spoke definition to config.yaml and regenerate the platform state:
kubara cluster add <spoke-name>
kubara generate --helmThe generated spoke-specific values are stored under:
platform-configs/<spoke-name>/helm/Generation also updates the Argo CD registration configuration on the hub. Once the reviewed state is committed and pushed, the configured secret integration provides the cluster credentials and Argo CD registers the spoke.
Cluster credentials should be scoped deliberately. Avoid granting broader cluster access than the platform requires, restrict managed namespaces where appropriate, and verify connectivity and authorization before rolling out platform services.
After registration, kubara-generated ApplicationSets can target clusters by label. This allows platform engineers to deploy a capability only to matching clusters without maintaining duplicate Argo CD Application definitions.
Core Capability 3: Establish Tenant-Aware GitOps Delivery
kubara supports tenant-aware GitOps delivery through Argo CD AppProjects rather than through a separate set of tenant commands. Platform engineers define these delivery boundaries in the hub's Argo CD overlay:
platform-configs/<hub-cluster-name>/helm/argo-cd/values-additional.yamlAn AppProject defines which source repositories, destination clusters, namespaces, and Kubernetes resource types a team may use. Together with Argo CD RBAC, it establishes who may deploy what and where. Repository credentials remain in the external secret backend and do not need to be stored in Git.
Applications connect an approved repository path to an AppProject and a permitted destination. ApplicationSets can generate multiple Applications from a shared definition, for example across clusters selected by labels.
The following example defines a delivery boundary for Team A, registers its workload repository, and deploys its applications to the spoke-dev cluster:
projects:
- name: team-a
description: Delivery boundary for Team A
sourceRepos:
- https://git.example.com/team-a/*
repositories:
- name: team-a-workloads
projectScope: team-a
url: https://git.example.com/team-a/workloads.git
remoteRef:
remoteKey: hub/production/team-a-repo
remoteKeyProperty: pat
bootstrapValues:
applications:
- name: team-a-apps
projectName: team-a
repoUrl: https://git.example.com/team-a/workloads.git
repoPath: apps
destination:
serverName: spoke-devThis model provides GitOps delivery boundaries and team-specific deployment scopes. Kubernetes-level tenant isolation — including network policies, resource quotas, runtime isolation, and access control within the target cluster — must still be designed separately.
Together, these capabilities cover platform generation, controlled evolution, multi-cluster delivery, and team-specific GitOps boundaries. Just as important, however, is understanding where kubara deliberately stops.
What kubara Is Not
kubara is intentionally focused on generating and evolving the desired state of a Kubernetes platform. Clear boundaries help explain where it fits within the wider platform-engineering ecosystem:
- It is not a Kubernetes distribution.
- It is not a continuously running platform controller.
- It does not replace Argo CD.
- It does not require Terraform and is not a cloud-infrastructure lifecycle manager.
- It is not a developer portal, source-code hosting platform, or CI system.
kubara's scope begins at the Kubernetes layer. Existing clusters are first-class starting points, while optional Terraform presets can support selected infrastructure scenarios. kubara generates and bootstraps the platform state; the surrounding tools remain responsible for infrastructure provisioning, continuous reconciliation, application development, and developer-facing workflows.
Recap: Where kubara Fits
kubara sits between the platform definition and continuous GitOps reconciliation. It combines a declarative contract with a reusable catalog, generates transparent platform state, and supports its controlled evolution across single-cluster and hub-and-spoke environments. It deliberately leaves infrastructure provisioning, continuous reconciliation, CI, source-code hosting, and developer-portal functionality to the tools designed for those responsibilities.
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.