Cozystack: A CNCF Sandbox Platform That Turns Bare Metal Into a Cloud API
Cozystack: Free Cloud Platform based on Kubernetes
At a glance
- What is it?
- Cozystack packages Kubernetes, KubeVirt, Cluster API and Talos into one installable platform with a REST API for tenant clusters, databases, VMs and load balancers. It is a strong fit for operators who want a private cloud on their own hardware, and a poor fit for anyone who wants a managed control plane or a single-node test box.
- Who is it for?
- Adopt Cozystack if you operate your own hardware and want a single control plane that spawns tenant Kubernetes clusters, databases, VMs and load balancers through one API, and you are willing to run that control plane yourself. Do not adopt it if you need a managed service, if your estate is a single node, or if you cannot absorb the upgrade cadence implied by a 1.6.x line that shipped three tags in eight days.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Cozystack fills between a Kubernetes install and a cloud product
Installing Kubernetes on bare metal is a solved problem. Turning that cluster into something a customer or an internal team can order from is not. The README frames Cozystack as a way to "transform a bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease." That list is the product: not a distribution, but a service layer that sits above one.
The audience is narrow and identifiable. The repository lists three use cases: building a public cloud, building a private cloud with an Infrastructure-as-Code approach, and using Cozystack as a Kubernetes distribution for bare metal. The first two are about selling or provisioning capacity to other people. The third is about running your own workloads on hardware you own. All three assume you have servers, not a cloud account.
What separates this from assembling the same components by hand is the API surface. A platform team that wires KubeVirt, Cluster API and a database operator together still has to build the ordering, tenancy and lifecycle layer. Cozystack ships that layer as the product, which is why the use-case docs are written around clouds rather than around clusters.
Kubernetes, KubeVirt, Cluster API and Talos as one stack
The topic list on the repository is the architecture in miniature: kubernetes, kubevirt, kvm, clusterapi, talos. Cozystack is not a new scheduler or a new container runtime. It composes existing projects and exposes them behind a unified control plane.
KubeVirt provides the virtual machine layer, which is how Cozystack offers VMs on hosts that are already running Kubernetes. Cluster API handles the lifecycle of Kubernetes clusters, which is how tenant clusters get created and managed. Talos appears as the node operating system, which matters because it makes the host layer declarative and API-driven rather than something you SSH into and patch. KVM is the underlying virtualization capability those VMs run on.
The README describes the project as both a platform and a framework. That word choice is deliberate. A framework implies the service catalogue is extensible, and the documentation points to a design proposal process in the community repository for cross-cutting or architectural changes. The practical consequence is that the set of services listed in the README is a starting catalogue, not a fixed one.
The Go codebase and Apache-2.0 licence are consistent with the rest: this is infrastructure meant to be forked, extended and embedded in someone else's product.
Getting it running: what the repository actually tells you
The README does not contain an install command. It points to the Getting Started section on cozystack.io and states that the documentation lives on that site. That is the honest position to take here: the install procedure is versioned documentation, not a snippet in the repository root, and reproducing a command I have not verified would be worse than saying where it lives.
What the material does establish is the operational entry points. The Getting Started guide is the install path. The troubleshooting guide is the documented first stop when something breaks, and the README explicitly says to start there and "work your way through the process that we've outlined" rather than opening an issue immediately. That ordering is a signal about where the maintainers expect friction to appear.
Versioning follows Semantic Versioning, and releases are listed in the GitHub Releases section. The most recent tags at the time of writing are v1.6.3, preceded by v1.6.3-rc.1 and v1.6.3-rc.2 in the days before it. The presence of release candidates ahead of a patch release indicates a staged process rather than tags pushed straight to stable.
For anything beyond that (the exact CLI flags, the chart values, the node prerequisites) the cozystack.io documentation is the source, and it is the only source this review can point to.
Where Cozystack is the wrong tool
The first limitation is structural. Cozystack is built to run on servers you control. Every use case in the README assumes hardware: a public cloud you operate, a private cloud you operate, bare metal as a Kubernetes distribution. If your infrastructure is already a managed Kubernetes service, adopting Cozystack means either running it on top of that service in a configuration the documentation does not present as a primary path, or buying hardware. Neither is a small decision.
The second is the control plane itself. A platform whose value is spawning tenant clusters and databases is a single point of coordination for all of them. That is true of every platform in this category, but it means the upgrade path of Cozystack is the upgrade path of your entire estate. The release cadence visible in the material supports taking that seriously: three tags within eight days for the 1.6.3 line. Frequent patch releases are normal for active infrastructure projects, and they also mean you need a tested rollback story before you upgrade a production control plane.
The third is scope. Cozystack is a CNCF Sandbox project. Sandbox is the earliest of the CNCF maturity stages, and the README states the project was originally built and sponsored by Ænix. That is not a criticism of the code; it is a statement about governance maturity and about who absorbs risk if the sponsoring company changes direction. A team that needs a vendor-backed SLA should read the support page before assuming one exists.
Finally, the README is thin on failure modes. It lists a troubleshooting guide but does not describe what happens when the platform API is unreachable, or how tenant workloads behave during a control-plane upgrade. Those answers live in the docs site, and a reader evaluating Cozystack should treat their absence from the README as a prompt to go read them.
How it differs from installing Rancher or Harvester yourself
The obvious comparison is to assembling the same primitives directly. KubeVirt gives you VMs on Kubernetes. Cluster API gives you cluster lifecycle. Talos gives you an immutable node OS. Each has its own documentation, its own release cadence and its own upgrade procedure, and each is a legitimate choice on its own.
The difference in approach is aggregation versus composition. If you assemble those projects yourself, you own the integration: the tenancy model, the API that sits in front of them, the way a database request becomes a running instance, and the upgrade ordering when one component moves. Cozystack takes that integration work and ships it as the artifact, which is why its selling point is a REST API rather than a component list.
The trade is control. With a hand-assembled stack you choose every version and can replace any layer without asking anyone. With Cozystack you get a tested combination and inherit its release schedule. For a small platform team, that trade is usually worth taking. For a large one with existing tooling and strong opinions about, say, which cluster lifecycle manager it uses, the aggregation is the part they already built.
A second comparison point is the node OS. Choosing Talos as the host layer is a commitment to an API-driven, immutable node model. That is a deliberate constraint, not a neutral default, and it shapes how you debug a misbehaving host.
Maintenance, upgrades and the Apache-2.0 licence
The maintenance cost of Cozystack is the maintenance cost of everything underneath it. You are running Kubernetes, KubeVirt, Cluster API and Talos, and the platform's release cycle is where those version bumps land. The SemVer promise in the README means minor versions can carry changes that require attention, and the 1.6.3 release train shows the project is actively patching. Neither fact tells you how long a given minor line is supported; the README does not state a support window, and the roadmap link on cozystack.io is where that would be documented.
Contributions route through a defined process rather than a single issue tracker. Bug reports go to GitHub Issues after checking for duplicates. Concrete feature requests also go to Issues. Cross-cutting or architectural changes go to a design proposal in the community repository. Questions and early ideas go to GitHub Discussions. CONTRIBUTING.md documents the routing. If you plan to carry patches, that structure tells you where a patch would need to be argued.
The licence is Apache-2.0, and the README states the code is provided as-is with no warranties. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes an explicit patent grant. It does not include any warranty or indemnity. If you build a commercial cloud on Cozystack, the licence permits it, and the support page at cozystack.io/support/ is where commercial backing is listed. This is a description of what the licence and README say, not legal advice; a lawyer should review any commercial deployment.
Who should install Cozystack, and what to check first
The fit is an operator with physical or dedicated servers who needs to hand out Kubernetes clusters, databases, VMs and load balancers to other people, and who would rather run one platform than maintain an integration of four. The Infrastructure-as-Code private cloud use case in the README describes that reader precisely.
The misfit is anyone whose infrastructure is a managed Kubernetes service, anyone running a single node, and anyone who cannot commit to tracking a fast patch cadence on a control plane that everything else depends on. Cozystack is also a poor choice if you need a formal support contract as a precondition of adoption and the support page does not list a provider covering your situation.
Before installing, verify three things. First, the exact component versions your target release pins, since the README does not state them. Second, the troubleshooting guide's coverage of control-plane failure, because that is the scenario that determines your blast radius. Third, whether the project's Sandbox status and its Ænix sponsorship match your organisation's tolerance for governance risk. The repository gives you the entry points; the cozystack.io documentation is where the answers have to come from.
Editorial conclusion
Adopt Cozystack if you operate your own hardware and want a single control plane that spawns tenant Kubernetes clusters, databases, VMs and load balancers through one API, and you are willing to run that control plane yourself. Do not adopt it if you need a managed service, if your estate is a single node, or if you cannot absorb the upgrade cadence implied by a 1.6.x line that shipped three tags in eight days. Before committing, read the getting-started and troubleshooting pages on cozystack.io, confirm the exact Kubernetes, Talos and KubeVirt versions your target release pins, and check the support page for whether a commercial backer covers your region.
Community notes