Project summary
KubeAid CLI operates the full lifecycle of Kubernetes clusters bootstrap, upgrade, recover, test, and delete across AWS, Azure, Hetzner, and generic bare metal, the GitOps-native way.
Project description
KubeAid CLI is a single self-contained binary that provisions and operates production Kubernetes clusters across multiple clouds and bare metal, with GitOps built in from the start rather than bolted on afterward.
For Cluster API–backed clouds (AWS via CAPA, Azure via CAPZ + Crossplane, Hetzner via CAPH), it stands up a throwaway K3D management cluster, installs Cluster API, provisions the target cluster, then pivots every Cluster API resource onto the target cluster itself so it becomes self-managing and the bootstrap cluster is discarded. For generic bare metal, it uses KubeOne instead, with no Cluster API layer at all. Either way, the result is the same: a cluster whose entire configuration lives as a Git commit in the user's own config repo, reconciled by ArgoCD Cilium, cert-manager, kube-prometheus, Rook-Ceph, Velero, and Sealed Secrets included. Day-2 operations are tested end to end on the KubeOne (bare metal) path today cluster sync/cluster upgrade reconcile changes onto a running cluster alongside built-in backup status reporting (backup status) surfacing CNPG and Velero backup health at a glance.
The gap it fills: today, operators either hand-roll Cluster API manifests and provider-specific tooling themselves, or adopt a heavier managed platform. KubeAid CLI sits in between a lightweight, provider-agnostic CLI that gives teams one consistent workflow to bootstrap, upgrade, recover, test, and delete clusters regardless of where they run, without requiring a long-lived management plane or vendor lock-in. Every change lands as an auditable, reproducible Git commit by design. It also ensures provider agnostic installation, making the change to a new provider easier as only minimal changes to the relevant manifests are needed.
Project vs Reference Architecture/Implementation
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/Obmondo/kubeaid-cli
Additional repos in scope of the application
No response
Website URL
https://github.com/Obmondo/kubeaid-cli
Roadmap
https://github.com/Obmondo/kubeaid-cli/blob/main/ROADMAP.md
Roadmap context
Two items flagged for the roadmap that aren't reflected there yet: day-2 cluster operations (cluster sync/upgrade for KubeOne-based bare metal, tested end-to-end along with backup status reporting), and Traefik as an ingress controller with GatewayAPI support in the pipeline.
Contributing guide
https://github.com/Obmondo/kubeaid-cli/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/Obmondo/kubeaid-cli/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/Obmondo/kubeaid-cli/blob/main/ADOPTERS.md
Maintainers file
https://github.com/Obmondo/kubeaid-cli/blob/main/MAINTAINERS.md
Security policy file
https://github.com/Obmondo/kubeaid-cli/blob/main/SECURITY.md
Standard or specification?
N/A
Business product or service to project separation
Obmondo (a managed Kubernetes services provider) built KubeAid CLI and uses it operationally to provision and operate its own customers' clusters (see https://github.com/Obmondo/kubeaid-cli/blob/main/ADOPTERS.md). It is the open-source tool underlying that offering, not a proprietary wrapper around it anyone can use the same binary to run their own clusters independently of any Obmondo service relationship. Project governance (see GOVERNANCE.md) runs on lazy consensus and maintainer votes open to any contributor regardless of employer, and releases/versioning are public and independent of Obmondo's own release cadence for its managed service.
Why CNCF?
Joining CNCF gives the project neutral governance, visibility to the broader Kubernetes operator community evaluating cluster-lifecycle tooling, and closer alignment with the upstream projects it already builds on and orchestrates (Cluster API, ArgoCD, Cilium, cert-manager, Prometheus). Sandbox specifically gives early feedback from a TAG before the project's conventions harden further.
Benefit to the landscape
Most existing cluster-lifecycle tools either focus on a single cloud, require hand-rolling Cluster API manifests directly, or bolt GitOps on as an afterthought. KubeAid CLI's differentiator is treating GitOps as the default operating model from the first bootstrap every provisioned cluster's state is a Git commit from day one while still unifying genuinely different provisioning mechanisms (Cluster API pivot for cloud, KubeOne for bare metal) behind one consistent CLI and workflow. The added visibility by joining CNCF could lead KubeAid CLI to handle more cloud providers through new contributions, thereby adding to the flexibility for its users and their choice of providers.
Cloud native 'fit'
The project is built entirely on cloud native primitives: Cluster API for declarative cluster provisioning, GitOps (ArgoCD) as the sole reconciliation path for addons, and Kubernetes-native tooling throughout (Cilium, Rook-Ceph, Sealed Secrets, kube-prometheus). It embodies the cloud native principle of declarative, Git-auditable infrastructure rather than imperative scripting.
Cloud native 'integration'
Depends on and orchestrates: Cluster API (CAPA/CAPZ/CAPH providers) for provisioning, ArgoCD for GitOps reconciliation, Cilium for CNI, cert-manager for TLS, kube-prometheus/Prometheus for monitoring, Rook-Ceph for storage, Sealed Secrets for secret management.
Cloud native overlap
Overlaps partially with Cluster API itself KubeAid CLI is a higher-level orchestrator built on top of CAPI, not a replacement for it; it doesn't compete with CAPI so much as remove the need to hand-write CAPI manifests and glue tooling directly.
Similar projects
Cluster API Operator, kOps, Kubespray, Rancher/RKE2 provisioning tooling, k0rdent, Sidero/Talos (bare-metal-focused). KubeAid CLI's differentiation is the GitOps-first design and the single-binary, no-long-lived-management-plane pivot model for cloud providers.
Landscape
no
Insights
created a discussion to add ourself linuxfoundation/insights#2080
Trademark and accounts
IP policy
Will the project require a license exception?
N/A project uses Apache 2.0.
Project "Domain Technical Review"
No response
Application contact email(s)
rishi@obmondo.com, klavs@obmondo.com
Contributing or sponsoring entity signatory information
| Name |
Address |
Type |
Signatory name and title |
Email address |
| EnableIT ApS |
Hædersdalvej 7, 2650 Hvidovre, Denmark |
Danish ApS (CVR 35518975) |
Klavs Klavsen, Founder & CEO |
klavs@obmondo.com |
CNCF contacts
No response
Additional information
KubeAid CLI has been in active development since 2024-08-28 (1355+ commits), comfortably clearing the 6-month minimum. Every current maintainer and nearly every contributor is currently an Obmondo employee flagging this proactively since org diversity is something the TOC weighs, even thoughit isn't a hard Sandbox requirement. We're open to growing a broader contributor base post-acceptance, which is part of the motivation for applying to CNCF Sandbox now.
Project summary
KubeAid CLI operates the full lifecycle of Kubernetes clusters bootstrap, upgrade, recover, test, and delete across AWS, Azure, Hetzner, and generic bare metal, the GitOps-native way.
Project description
KubeAid CLI is a single self-contained binary that provisions and operates production Kubernetes clusters across multiple clouds and bare metal, with GitOps built in from the start rather than bolted on afterward.
For Cluster API–backed clouds (AWS via CAPA, Azure via CAPZ + Crossplane, Hetzner via CAPH), it stands up a throwaway K3D management cluster, installs Cluster API, provisions the target cluster, then pivots every Cluster API resource onto the target cluster itself so it becomes self-managing and the bootstrap cluster is discarded. For generic bare metal, it uses KubeOne instead, with no Cluster API layer at all. Either way, the result is the same: a cluster whose entire configuration lives as a Git commit in the user's own config repo, reconciled by ArgoCD Cilium, cert-manager, kube-prometheus, Rook-Ceph, Velero, and Sealed Secrets included. Day-2 operations are tested end to end on the KubeOne (bare metal) path today cluster sync/cluster upgrade reconcile changes onto a running cluster alongside built-in backup status reporting (backup status) surfacing CNPG and Velero backup health at a glance.
The gap it fills: today, operators either hand-roll Cluster API manifests and provider-specific tooling themselves, or adopt a heavier managed platform. KubeAid CLI sits in between a lightweight, provider-agnostic CLI that gives teams one consistent workflow to bootstrap, upgrade, recover, test, and delete clusters regardless of where they run, without requiring a long-lived management plane or vendor lock-in. Every change lands as an auditable, reproducible Git commit by design. It also ensures provider agnostic installation, making the change to a new provider easier as only minimal changes to the relevant manifests are needed.
Project vs Reference Architecture/Implementation
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/Obmondo/kubeaid-cli
Additional repos in scope of the application
No response
Website URL
https://github.com/Obmondo/kubeaid-cli
Roadmap
https://github.com/Obmondo/kubeaid-cli/blob/main/ROADMAP.md
Roadmap context
Two items flagged for the roadmap that aren't reflected there yet: day-2 cluster operations (cluster sync/upgrade for KubeOne-based bare metal, tested end-to-end along with backup status reporting), and Traefik as an ingress controller with GatewayAPI support in the pipeline.
Contributing guide
https://github.com/Obmondo/kubeaid-cli/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/Obmondo/kubeaid-cli/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/Obmondo/kubeaid-cli/blob/main/ADOPTERS.md
Maintainers file
https://github.com/Obmondo/kubeaid-cli/blob/main/MAINTAINERS.md
Security policy file
https://github.com/Obmondo/kubeaid-cli/blob/main/SECURITY.md
Standard or specification?
N/A
Business product or service to project separation
Obmondo (a managed Kubernetes services provider) built KubeAid CLI and uses it operationally to provision and operate its own customers' clusters (see https://github.com/Obmondo/kubeaid-cli/blob/main/ADOPTERS.md). It is the open-source tool underlying that offering, not a proprietary wrapper around it anyone can use the same binary to run their own clusters independently of any Obmondo service relationship. Project governance (see GOVERNANCE.md) runs on lazy consensus and maintainer votes open to any contributor regardless of employer, and releases/versioning are public and independent of Obmondo's own release cadence for its managed service.
Why CNCF?
Joining CNCF gives the project neutral governance, visibility to the broader Kubernetes operator community evaluating cluster-lifecycle tooling, and closer alignment with the upstream projects it already builds on and orchestrates (Cluster API, ArgoCD, Cilium, cert-manager, Prometheus). Sandbox specifically gives early feedback from a TAG before the project's conventions harden further.
Benefit to the landscape
Most existing cluster-lifecycle tools either focus on a single cloud, require hand-rolling Cluster API manifests directly, or bolt GitOps on as an afterthought. KubeAid CLI's differentiator is treating GitOps as the default operating model from the first bootstrap every provisioned cluster's state is a Git commit from day one while still unifying genuinely different provisioning mechanisms (Cluster API pivot for cloud, KubeOne for bare metal) behind one consistent CLI and workflow. The added visibility by joining CNCF could lead KubeAid CLI to handle more cloud providers through new contributions, thereby adding to the flexibility for its users and their choice of providers.
Cloud native 'fit'
The project is built entirely on cloud native primitives: Cluster API for declarative cluster provisioning, GitOps (ArgoCD) as the sole reconciliation path for addons, and Kubernetes-native tooling throughout (Cilium, Rook-Ceph, Sealed Secrets, kube-prometheus). It embodies the cloud native principle of declarative, Git-auditable infrastructure rather than imperative scripting.
Cloud native 'integration'
Depends on and orchestrates: Cluster API (CAPA/CAPZ/CAPH providers) for provisioning, ArgoCD for GitOps reconciliation, Cilium for CNI, cert-manager for TLS, kube-prometheus/Prometheus for monitoring, Rook-Ceph for storage, Sealed Secrets for secret management.
Cloud native overlap
Overlaps partially with Cluster API itself KubeAid CLI is a higher-level orchestrator built on top of CAPI, not a replacement for it; it doesn't compete with CAPI so much as remove the need to hand-write CAPI manifests and glue tooling directly.
Similar projects
Cluster API Operator, kOps, Kubespray, Rancher/RKE2 provisioning tooling, k0rdent, Sidero/Talos (bare-metal-focused). KubeAid CLI's differentiation is the GitOps-first design and the single-binary, no-long-lived-management-plane pivot model for cloud providers.
Landscape
no
Insights
created a discussion to add ourself linuxfoundation/insights#2080
Trademark and accounts
IP policy
Will the project require a license exception?
N/A project uses Apache 2.0.
Project "Domain Technical Review"
No response
Application contact email(s)
rishi@obmondo.com, klavs@obmondo.com
Contributing or sponsoring entity signatory information
CNCF contacts
No response
Additional information
KubeAid CLI has been in active development since 2024-08-28 (1355+ commits), comfortably clearing the 6-month minimum. Every current maintainer and nearly every contributor is currently an Obmondo employee flagging this proactively since org diversity is something the TOC weighs, even thoughit isn't a hard Sandbox requirement. We're open to growing a broader contributor base post-acceptance, which is part of the motivation for applying to CNCF Sandbox now.