# Cozystack: a Kubernetes-native cloud platform that turns bare metal into a service catalog

> Cozystack is a CNCF Sandbox project, Apache-2.0 licensed, that layers a REST API and a service catalog over Kubernetes. It is aimed at operators who want to offer clusters, databases and VMs from their own hardware, and it is not a small install.

**cozystack/cozystack** — Cozystack: Free Cloud Platform based on Kubernetes

- Repository: https://github.com/cozystack/cozystack
- Website: https://cozystack.io
- Stars: 2,243 · Forks: 208
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/cozystack-cozystack

## What Cozystack is trying to replace

Most teams that want to hand out Kubernetes clusters, databases or virtual machines end up integrating the same parts themselves: a cluster API provider, a storage layer, a load balancer, an ingress or caching tier, an operator per database engine. Cozystack's pitch is that you install one platform and get those services as objects you create through an API. The README describes it as a free platform and framework for building clouds, and lists three use cases: a public cloud backend, a private cloud driven by Infrastructure-as-Code, and a Kubernetes distribution for bare metal.

The intended user is an operator, not an application developer. Someone with a rack of servers, or a provider renting servers, who wants a self-service catalog. The README's own summary is that you 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 and HTTP caching services. If your requirement is one cluster for one team, this is more platform than the problem needs.

## The mechanism: packages, controllers and Flux

The repository layout is the clearest statement of how Cozystack works. There is a packages/ directory holding per-component definitions, and the Makefile builds images for each of them by descending into subdirectories: packages/apps/http-cache, packages/apps/mariadb, packages/apps/clickhouse, packages/apps/kubernetes, packages/system/cozystack-api, packages/system/cozystack-controller, packages/system/backup-controller, packages/system/backupstrategy-controller, packages/system/lineage-controller-webhook, packages/system/flux-shard-operator, and system packages for Cilium, LINSTOR, Kube-OVN, MetalLB, Kamaji, Cluster API providers, Multus, Grafana, Redis and OpenSearch.

That list is the architecture in one line: Cozystack is a curated set of Helm packages plus its own controllers, reconciled by Flux. The go.mod confirms the dependency direction, pulling in fluxcd/helm-controller, source-controller and source-watcher APIs, controller-runtime, the Cluster API ecosystem through Kamaji and capi providers, KubeVirt for virtual machines, Velero for backups, and the container-object-storage-interface API. The cozystack-api package is what exposes the REST surface the README advertises.

The practical consequence is that Cozystack does not abstract Kubernetes away. A tenant cluster is still a Kubernetes cluster; a MariaDB instance is still an operator-managed database. Cozystack's contribution is the packaging, the API in front of it, and the controllers that keep the pieces consistent.

## Installing Cozystack and creating a first service

The README does not contain install commands. It points to the Getting Started section on cozystack.io, and the Makefile is a developer build path, not a user install path: it requires find, docker, skopeo, jq, gh, helm, mikefarah/yq, GNU tar, GNU sed and GNU awk before it will run, and then builds images component by component. That is for people working on Cozystack itself.

For an operator, the documented route is the Getting Started guide on the project site. Because the repository ships packages for Talos, Cilium, LINSTOR, Kube-OVN and MetalLB, the install is a full platform deployment onto servers, not a Helm chart added to an existing cluster. The exact command sequence, supported providers and prerequisites live in that guide; the README is silent on them, so treat cozystack.io as the source of truth for the install itself.

Once the platform is up, the workflow is API-shaped. The repository carries an api/ directory and a cozystack-api system package, and the README describes the result as a REST API for spawning services. The examples/ directory includes an examples/backups/ entry, which is the one concrete example path visible in the repository listing. For anything beyond that, the per-service documentation on the site is where the object shape is defined; the README gives the category, not the schema.

## Where Cozystack is the wrong choice

The build dependency list is a fair proxy for the operational surface. A platform that ships its own Cilium, LINSTOR, Kube-OVN, MetalLB, Kamaji, Grafana and OpenSearch packages is a platform you upgrade as a unit. If your organisation already has a networking stack, a storage stack and a monitoring stack it is happy with, Cozystack will either replace them or fight them. The README does not describe a supported path for bringing your own CNI or your own storage backend.

Second, the README does not document rollback, and it does not document an upgrade procedure at all. Versioning follows Semantic Versioning and releases are listed on GitHub, but the README itself is silent on what happens when a platform upgrade goes wrong. That silence matters more here than for a single-purpose operator, because the upgrade touches the network and storage layers that tenant workloads depend on.

Third, this is a CNCF Sandbox project originally built and sponsored by a single company, Ænix. Sandbox is an early stage in the CNCF lifecycle. The repository is not archived and the last push was on 2026-09-10, with v1.6.3 released on 2026-09-04, so the code is moving. But a platform that owns your network and storage is a long-lived dependency, and the governance and maintainer documents in the repository root are worth reading before you bet a production cloud on it.

## Cozystack compared with OpenStack and with plain Talos

The question people ask most is how Cozystack differs from OpenStack. The difference is in the control plane, not the feature list. OpenStack is a set of services with their own APIs, their own database, their own message queue and their own identity system; you can run Nova without Neutron if you want to. Cozystack is a Kubernetes distribution plus a service catalog on top of it, and its control plane is the Kubernetes control plane. Tenant clusters are Kubernetes clusters; virtual machines run through KubeVirt, which the topics list confirms. There is no separate identity service to operate, and no RabbitMQ to keep alive.

The cost of that choice is that everything inherits Kubernetes failure modes. If the platform cluster is unhealthy, the catalog is unavailable, and so is every tenant cluster's lifecycle management. OpenStack has more moving parts but also more isolation between them.

Against Talos, the comparison is different. Talos is an operating system for Kubernetes nodes; Cozystack is the layer above, and the packages/system tree includes Talos among the things it deploys. Choosing Talos alone means you still assemble networking, storage, load balancing and the tenant-facing API yourself. Choosing Cozystack means accepting its choices for all of those. Against Rancher, the split is similar: Rancher manages clusters you already have or provisions them on existing infrastructure, while Cozystack starts from the servers and builds the infrastructure underneath.

## Licence, maintenance and upgrade cost

Cozystack is Apache-2.0, and the README states the code is provided as-is with no warranties. Apache-2.0 is permissive: you can run it commercially, modify it and redistribute it, subject to the usual notice and attribution conditions. That matters for the public-cloud use case the README lists, because it means there is no licence barrier to reselling the platform as a service. It does not mean the project owes you support. Commercial support is a separate offering listed on cozystack.io/support, and the README routes support questions there.

On maintenance, the honest framing is that Cozystack is a large surface. The Makefile builds roughly two dozen component images, and each of those is a dependency you inherit. Upgrading Cozystack means upgrading the packaged versions of Cilium, LINSTOR, Kube-OVN, MetalLB, Kamaji and the rest in a coordinated way, which is the point of the packaging and also the cost of it. The repository has a ROADMAP.md and a GOVERNANCE.md, and the project runs weekly community meetings with a public calendar, so the process is visible even where the README is thin.

## Conclusion

Adopt Cozystack if you already run Kubernetes and want to sell or hand out clusters, databases and VMs from your own hardware without assembling a control plane from a dozen projects. Do not adopt it if you need a single-node lab, a managed control plane, or a platform you can reason about without reading the operations documentation, because the packages tree shows how much of the stack Cozystack owns. Before committing, verify the supported install path for your provider, the backup and restore procedure for your storage backend, and whether the release you are pinning has an upgrade note that applies to you.

## FAQ

### What are the key differences between Cozystack and OpenStack?

Cozystack's control plane is Kubernetes, and its services are Kubernetes objects created through a REST API, while OpenStack is a set of independent services with their own APIs and datastores. Cozystack runs virtual machines through KubeVirt and tenant clusters through Cluster API providers, so everything shares the Kubernetes failure domain. The README positions Cozystack as a platform and framework for building clouds, including as a backend for a public cloud.

### What is Cozystack?

It is a free platform and framework for building clouds, described in the README as a way to transform a bunch of servers into a system with a REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers and HTTP caching services. It is a CNCF Sandbox project originally built and sponsored by Ænix, and it is licensed under Apache-2.0.

### How does Cozystack compare with Talos?

Talos is an operating system for Kubernetes nodes, and Cozystack ships a Talos package among its system components, so the two operate at different levels. Cozystack adds the networking, storage, load balancing and tenant-facing API layers on top, which means adopting it means accepting its choices for all of those. The README does not document replacing the packaged components with your own.

## Sources

- [cozystack/cozystack on GitHub](https://github.com/cozystack/cozystack)
- [License: Apache-2.0](https://github.com/cozystack/cozystack/blob/main/LICENSE)
- [Project website](https://cozystack.io)
- [README](https://github.com/cozystack/cozystack/blob/main/README.md)
- [Releases](https://github.com/cozystack/cozystack/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cozystack-cozystack