Cozystack has completed the CNCF General Technical Review (GTR). The review is the technical half of the due diligence a project goes through on its way from Sandbox to Incubation. Where conformance programmes ask whether a platform behaves as a standard says it should, the GTR asks the questions an operator asks before trusting a platform in production: how it is installed, how it is upgraded and rolled back, what it costs to run, how it fails, and how security issues are found and fixed.
The questionnaire is answered in full and kept in the project repository as
GENERAL_TECHNICAL_REVIEW.md.
A dated snapshot is filed with the CNCF Technical Oversight Committee in
cncf/toc#2305, alongside the Cozystack
incubation application. This page summarises what
the review records; the document itself is the source of every figure below.
The template follows the life of a platform in three phases, and each answer points at code, documentation or a measurement rather than at intentions.
The review is answered for Cozystack v1.6.3, the latest stable release at the time of submission.
One correction to a common assumption is worth stating first, because the review makes it explicit: Cozystack is not Talos-only. Talos Linux is the recommended path, where the platform owns the nodes and they run immutable, with no SSH and no shell. The same platform also installs on generic Linux — Ubuntu, Debian, RHEL, Rocky or openSUSE — through the Ansible collection, which bootstraps k3s, and onto an existing Kubernetes cluster. Every path recommends at least three servers.
The questions about overhead, scale and upgrades were answered by running the platform rather than by estimating. The bench was three servers with 32 vCPU and 128 GB of memory each, installed on the generic Linux path.
| What was measured | Result |
|---|---|
| Idle platform overhead | about 1 CPU core and 19 GiB of memory across all three nodes, before any tenant workload |
| Concurrent managed databases | 71 PostgreSQL instances, each with a replicated volume, with no failures and no node pressure |
| Mixed load across application types | about 76 applications and 402 pods — tenants, VMs, Redis, MariaDB, ClickHouse, Kafka — all Ready |
| Upgrade to the next patch release | converged in about 175–200 seconds |
| Downgrade back | converged in about 250 seconds |
| Data across upgrade and downgrade | every replicated volume survived all four version changes |
The ceiling the bench reached was not compute, memory or storage. It was the kubelet
max-pods limit and the throughput of the Flux helm-controller — and when the helm-controller
became congested, Cozystack’s shard operator added a second shard on its own. The review also
records one upgrade-time hazard found on the bench: after a control-plane node is replaced,
the address of the original node must be repointed in the CNI configuration, or service
networking can drop during the next reconcile.
The review is filed together with the Cozystack security self-assessment, threat model and incident-response process. It describes how vulnerabilities reach the project and how fast they are handled:
docs/security/reports/,
with identifiers withheld until a fix has shipped.A review that lists only strengths is not useful to anyone evaluating a platform, and this one records its gaps plainly:
v1alpha1;NOTICE file aggregating attribution for the bundled components;Each of these is tracked in the open, and the review links to the issue where one exists.
The review follows version 1.0 of the CNCF
General Technical Review template.
Bench measurements were taken on 18–19 September 2026 on the generic Linux path with the
isp-full-generic variant.