Cozystack: Why Transparency Matters in a Private Cloud

A CNCF project published a technical review of its own platform, including the things it still needs to fix. That is what made me stop and read.

The project is Cozystack, an open-source platform for delivering cloud services on infrastructure you control. Its promise includes managed Kubernetes clusters, virtual machines, databases, and messaging services. The more interesting question is how much evidence exists behind that promise.

In my LinkedIn post, I focused on the project’s willingness to publish both measurements and gaps. This article takes that argument further: what the results actually demonstrate, how the architecture fits together, and what I would want to validate before trusting it with production workloads.

This is an assessment of published evidence, not a report of a production deployment I have operated. The versions and review status discussed below were checked on October 22, 2026.

A Technical Review Is More Useful Than Another Feature List

Cozystack announced completion of its General Technical Review on September 29. The dated review snapshot was subsequently merged into the CNCF Technical Oversight Committee repository on October 1. It forms part of the project’s Incubation due diligence. That milestone should not be confused with promotion: the CNCF project page still lists Cozystack at the Sandbox maturity level. (Review announcement , CNCF review record , CNCF project page )

For an infrastructure team, the value of this exercise is the shift in the conversation. A feature list describes what a platform can provision. A technical review asks what happens before installation, during a change, and after something fails.

Those are the questions that determine whether a service is operable. Who can explain a failed reconciliation? Which dependencies must be upgraded together? What evidence would justify a rollback? Which parts of the system are still outside the test coverage?

Publishing answers makes an evaluation more concrete. It also makes unanswered questions harder to hide.

What the Reference Bench Actually Shows

The review describes a three-server bench, with 32 vCPU and 128 GB of memory per server. It used the generic Linux installation path, rather than Talos. The measurements were taken on September 18–19, 2026. These details matter: three nodes describe a topology, not a universally small hardware footprint.

The review also identifies limits around the kubelet pod count and Flux reconciliation throughput. Its remaining validation work includes a fresh three-node HA run and measurements on the Talos path. (Published reference-bench results )

I find these numbers useful because they establish a baseline for further testing. They should not be stretched into guarantees they were never designed to provide.

Seventy-one provisioned PostgreSQL instances do not tell us how many transaction-heavy databases the platform can sustain at an acceptable latency. An idle CPU figure is not a capacity plan. Upgrade convergence time is not automatically application downtime, and retaining a volume does not by itself establish application-level consistency.

For an evaluation, I would reproduce the baseline first, then add a workload that resembles the intended service: its data size, write rate, connection count, and recovery objectives. I would measure client-visible behaviour throughout an upgrade and a failure, rather than stopping when the controllers report Ready.

That is how published measurements become useful engineering inputs.

How Bare Metal Becomes a Service Platform

Cozystack brings together infrastructure components behind a common platform model. The documented stack includes Talos Linux, Kubernetes, KubeVirt, Kamaji, Cluster API, LINSTOR/DRBD, and Flux. Talos is the recommended operating-system path, but the platform also supports other deployment paths; the benchmark above should therefore not be presented as a Talos benchmark. (Platform stack , Deployment models in the review )

This is a simplified architecture overview, not a complete deployment diagram. Networking in particular is more involved than saying “Cilium does everything”; Cozystack documents the responsibilities of its network layers separately. (Network architecture )

The tenant Kubernetes model is especially relevant. Kamaji runs tenant control planes as pods in the management cluster, while KubeVirt provides virtual worker machines. Cluster API coordinates their lifecycle. A tenant cluster therefore has its own control plane and worker environment, rather than being just a namespace in the provider’s cluster. (Managed Kubernetes implementation )

My interest is in the operating model this enables. A platform team can offer a defined service instead of handing every application team a collection of installation instructions. The service still needs an owner, an upgrade policy, and a recovery procedure. Packaging the components together makes those responsibilities more consistent; it does not make them disappear.

The Unfinished Work Is Part of the Evaluation

The published review records gaps in release-image signing, build provenance, API stability policy, and aggregated component attribution. It also calls out missing default audit policy, limitations in scheduled end-to-end testing, and additional upgrade validation still to perform. These are findings recorded in the review, not a claim that every item will remain unresolved indefinitely. (Technical review document )

Each gap has a practical consequence for an adopter.

Supply-chain evidence affects what you can admit into production. If your deployment policy requires signed images and verifiable provenance, a public issue describing that missing work is useful, but it does not satisfy the policy. You need to establish which controls exist for the exact release you intend to run.

API stability affects the cost of automation. A platform API becomes part of your infrastructure code, service portal, and operational tooling. Before building heavily on it, I would want a clear answer about compatibility, deprecation, and migration support.

Attribution affects redistribution and internal review. An aggregate NOTICE file is less visible than a dashboard feature, but a platform bundles many upstream components. Understanding that inventory belongs in adoption planning.

Test coverage affects confidence in changes. A passing test demonstrates a particular scenario. It does not answer every question about topology, workload, or failure mode. Knowing what has not been rerun helps an evaluator spend testing time where it matters.

Transparency earns attention because it makes risk discussable. Closing the gaps, maintaining the evidence, and responding predictably to problems are what build confidence over time.

Why the 1.6 Changes Matter to Operators

The 1.6 release introduced Talos-based tenant workers through Cluster API, tenant-controlled OIDC for Kubernetes and Grafana, a SecurityGroup API, and hierarchical quotas. These changes move beyond adding another service to the catalog: they address how a shared platform is governed. (Cozystack 1.6 release announcement )

Identity integration determines how users enter and leave a service. A network-policy abstraction determines whether tenants can express access rules without depending on a platform administrator for every change. Quotas help turn finite hardware into explicit service boundaries.

The worker change also illustrates why release notes matter. The project describes a rolling replacement of existing workers when moving to the new Talos model. That is materially different from the patch upgrade timing measured on the reference bench. (Worker migration details )

I would treat that rollout as a workload event: check disruption budgets, available spare capacity, storage attachment behaviour, and how applications recover after a worker replacement. A platform can automate the sequence while application readiness still determines the experience users see.

AI Conformance: A Useful, Bounded Signal

Cozystack publishes Kubernetes conformance results for its tenant clusters, including accepted v1.34 and v1.35 submissions. This provides evidence about Kubernetes compatibility for the tested product and versions. (Kubernetes conformance results )

The AI conformance evidence is more specific: the project reports an accepted v1.35 self-assessment submitted by Ænix for Cozystack v1.6.1, with all twelve requirements met. Its detailed checks used a tenant cluster running Kubernetes v1.35.6. The documented capabilities include accelerator integration, GPU sharing, routing, scheduling, and observability; some require enabling addons or installing additional components. (AI conformance evidence and configuration )

That makes it a useful starting point for evaluating AI infrastructure. It does not establish how quickly a particular model will train, what inference latency it will achieve, or whether a proposed GPU configuration meets your isolation requirements.

For inference, I would test model loading time, sustained throughput, tail latency, and behaviour during worker replacement. For training, I would examine checkpoint recovery, data access, scheduling under contention, and the network requirements of the actual workload.

The conformance result helps narrow the compatibility questions. Performance and operating cost still need their own evidence.

A Credible Option for Private Cloud in Europe

My original post framed Cozystack as a third path alongside OpenStack and VMware. That captures a familiar procurement discussion, but it is not an exhaustive map of the market. There are other virtualization platforms, Kubernetes distributions, and managed-service approaches worth considering.

The reason Cozystack interests me is more specific: it offers a Kubernetes-native approach to providing several kinds of services on infrastructure an organization controls. For teams already comfortable with controllers, declarative configuration, and GitOps, that is an operating model worth examining.

The comparison should begin with the service you need to deliver. A predominantly VM-based estate, a provider selling managed databases, and an internal AI platform have different requirements. A feature matrix alone will not settle the choice.

Digital sovereignty also needs a practical definition. Where do the data and backups reside? Who controls privileged access and encryption keys? Can the organization restore its services without depending on one supplier? Does it understand the upstream dependencies it inherits?

Open source supports inspection and gives teams more options, but operational control requires people, procedures, and tested recovery. Hosting software on European hardware does not answer all of those questions on its own.

What I Would Put in a Proof of Concept

I would give a Cozystack evaluation a small set of explicit acceptance criteria:

1. Reproduce a documented baseline on the intended deployment path and record the exact versions, hardware, and enabled services.
2. Exercise representative stateful workloads, including a restore from backup into a clean environment. Replication and backup solve different problems.
3. Test tenant boundaries, including identity changes, network access, resource contention, and quota behaviour.
4. Run a supported upgrade with clients active, recording availability and data correctness as well as controller convergence.
5. Practise a recovery scenario, then have another engineer follow the runbook without relying on the original installer’s memory.

I would also count the engineering time spent operating the platform. The cost of a private cloud includes incident response, upgrades, spare capacity, and the ability to keep expertise in the team.

These tests would give me a stronger basis for a decision than either enthusiasm for the architecture or concern about an openly documented gap.

Cozystack deserves attention because it is making that kind of evaluation possible. The published results give us something to reproduce; the unfinished work tells us where to look more closely.

I trust a project more when it makes its limitations inspectable. The next step is to test those limits against the service I actually need to run.