Review Project Moving Level Evaluation

• I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

Cozystack Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): cozystack/cozystack
Project Site: cozystack.io
Sub-Projects (categorised per GOVERNANCE.md by whether a repository's output ships in the distribution):

Packaged sub-projects — built or vendored into the Cozystack release (Apache-2.0, in scope for the same release/security/licence/maintainership expectations as the main repo):

• etcd-operator
• cozy-proxy
• keycloak-kms-proxy
• local-ccm
• cozystack-scheduler
• ingress-nginx-with-protobuf-exporter
• plus the apimachinery fork, compiled in via a go.mod replace (temporary, pending the upstream fix)

Standalone tooling — governed by the project, installed separately, not part of the release:

• talm
• cozyhr
• cozyvalues-gen
• terraform-provider-cozystack
• ansible-cozystack
• boot-to-talos
• talos-bootstrap
• talos-meta-tool
• blockstor

Project infrastructure — no shipped code:

• website, community, external-apps-example, ccp, .github, .project
• cozystack-telemetry-server — infrastructure, but clusters report to it by default (documented, opt-out)

(Removed from the earlier list: cozystack-ui — archived, its console vendored into the main repo at packages/system/dashboard/images/console; cozypkg — the package-management CLI, built from cmd/cozypkg in the main repo. etcd-operator moved from the aenix-io org to cozystack.)

Communication: CNCF Slack, Kubernetes Slack, Telegram, GitHub Discussions

Project points of contacts:

The Cozystack Maintainers

Active Maintainers

Emeritus Maintainers

The project thanks the following former maintainers for their contributions; their move to Emeritus status was documented in PR #2717 following the Stepping Down / Emeritus Process.

• (Post Incubation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Incubation Criteria Summary for Cozystack

Application Level Assertion

• This project is currently Sandbox, accepted on 2025/03/02, and applying to Incubation.
• This project is applying to join the CNCF at the Incubation level.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

• Ænix
• Mediatech
• Gohost
• Urmanac
• HIDORA
• QOSI
• Cloupard
• BeBy Cloud
• Protofire
• Cloudsy

A further 10–15 organizations use Cozystack in production but cannot be listed publicly. Contact details for verified adopters have been shared privately with the TOC.

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.

  • Presented at TAG Infrastructure meeting on 05-Nov-2025: https://youtu.be/gJ4GYeLB-V0?si=S8Wrv1H7aLtBkZ9R&t=2066
  • Slides: https://github.com/user-attachments/files/23371109/Cozystack.pdf
  • General Technical Review questionnaire (in progress): docs: add CNCF General Technical Review (GTR) questionnaire cozystack/cozystack#3572

• All project metadata and resources are vendor-neutral.

Yes. Cozystack uses CNCF-provided vendor-neutral resources for communication, testing, hosting, and governance.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

• Met during project's application on 09-Jan-2025.

• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

• End user documentation

• Installation documentation

• Use cases / guides

• Ænix blog posts

Governance and Maintainers

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

Cozystack governance is based on CNCF best practices and continues to evolve with community growth. The project currently has 8 active maintainers across 4 organizations (Ænix, Urmanac, HIDORA, Independent), plus 2 maintainers in documented Emeritus status, and has received contributions from 40+ contributors across 15+ companies. Single-vendor concentration in the active maintainer group is 37.5% (Ænix), with the remaining 62.5% spread across Urmanac, HIDORA, and Independent affiliations.

• Clear and discoverable project governance documentation.

• MAINTAINERS.md

• GOVERNANCE.md

• CONTRIBUTOR_LADDER.md

• CONTRIBUTING.md

• Cozystack Community Meetings Calendar

• Cozystack Community Meetings Recordings

• Cozystack Meetings Notes

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

Yes.

• Governance clearly documents vendor-neutrality of project direction.

Included in Code of Conduct and demonstrated by the multi-vendor maintainer composition.

• Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

• GOVERNANCE.md

• CONTRIBUTOR_LADDER.md

• CONTRIBUTING.md

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams.

• GOVERNANCE.md

• CONTRIBUTOR_LADDER.md

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

• GOVERNANCE.md

• CONTRIBUTOR_LADDER.md — including the Stepping Down / Emeritus Process

• CONTRIBUTING.md

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

The project has applied the maintainer lifecycle process in both directions since joining the Sandbox:

• Maintainer roster update after joining CNCF

• Onboarded two additional maintainers from HIDORA (@matthieu-robin, @mattia-eleuteri) reflecting active multi-vendor contribution since Sandbox.

• First documented use of the Emeritus process for @aobort and @klinch0 in PR #2717, with the Active Maintainers / Emeritus Maintainers separation added to MAINTAINERS.md at the same time. Two further maintainers (@gecube, @nbykov0) updated their public affiliations to Independent, and @lllamnyp's affiliation was updated to Ænix. As a result, Ænix's share of the active maintainer group decreased from 50% to 37.5%.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

Subprojects share the parent project's governance, contribution, and maintainer-lifecycle rules (GOVERNANCE.md). Sub-project leads are listed in their respective MAINTAINERS.md files.

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

MAINTAINERS.md

• A number of active maintainers which is appropriate to the size and scope of the project.

8 active maintainers across 4 organizations (Ænix, Urmanac, HIDORA, Independent). 2 additional maintainers in documented Emeritus status.

• Code and Doc ownership in GitHub and elsewhere matches documented governance roles.

CONTRIBUTING.md, CODEOWNERS.

• Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.

Code of Conduct

• CNCF Code of Conduct is cross-linked from other governance documents.

Yes. Linked from GOVERNANCE.md, CONTRIBUTING.md, CONTRIBUTOR_LADDER.md.

• All subprojects, if any, are listed.

Categorised per GOVERNANCE.md → Sub-projects by whether a repository's output ships in the distribution:

Packaged sub-projects — built or vendored into the Cozystack release (Apache-2.0, in scope for the same release/security/licence/maintainership expectations as the main repo):

• etcd-operator
• cozy-proxy
• keycloak-kms-proxy
• local-ccm
• cozystack-scheduler
• ingress-nginx-with-protobuf-exporter

Independent tooling — governed by the project, installed separately, not part of the release:

• talm, cozyhr, cozyvalues-gen, terraform-provider-cozystack, ansible-cozystack, boot-to-talos, talos-bootstrap, talos-meta-tool, blockstor

Sub-projects follow the parent project's governance, contribution, and maintainer-lifecycle rules (GOVERNANCE.md); per-repo reviewers are recorded in each repository's CODEOWNERS and in the Packaged sub-projects table. (Removed from the earlier draft: cozypkg, built from cmd/cozypkg in the main repo; cozystack-ui, archived with its console vendored into packages/system/dashboard; cozystack-telemetry-server, not a governed sub-project. etcd-operator now lives in the cozystack org, not aenix-io.)

Contributors and Community

Suggested

• Contributor ladder with multiple roles for contributors.

https://github.com/cozystack/cozystack/blob/main/CONTRIBUTOR_LADDER.md

Required

• Clearly defined and discoverable process to submit issues or changes.

https://github.com/cozystack/cozystack/blob/main/CONTRIBUTING.md

• Project must have, and document, at least one public communications channel for users and/or contributors.

Documented in README.md.

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

CNCF Slack, Kubernetes Slack, Telegram, GitHub Discussions. No non-public channels are used for project work.

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

• Cozystack Community Meetings Calendar

• Cozystack Community Meetings Recordings

• Cozystack Meetings Notes

• Documentation of how to contribute, with increasing detail as the project matures.

https://github.com/cozystack/cozystack/blob/main/CONTRIBUTING.md

• Demonstrate contributor activity and recruitment.

Cozystack DevStat Dashboard

Engineering Principles

Suggested

• Roadmap change process is documented.

Community Roadmap

• History of regular, quality releases.

Releases

Since joining CNCF Sandbox on March 4, 2025, Cozystack has delivered five stable minor releases (v1.1, v1.2, v1.3, v1.4, v1.5) and more than twenty patch releases on a predictable cadence, with public release candidates, long-lived patch branches, and automated backports. The most significant milestones include:

• Reached v1.0.0 stable: first stable major release.
• Introduced an operator-driven platform architecture: declarative Package / PackageSource model, automated CRD lifecycle management, and Flux sharding for multi-tenant scalability.
• Built a comprehensive backup and restore framework: backup plans, restore jobs, Velero integration, native VM backup, RestoreJob dashboard, cross-namespace VM restore, and declarative BackupStrategy for PostgreSQL, MariaDB, ClickHouse, and FoundationDB (v1.4).
• Significantly advanced virtualization support: GPU support for VMs and tenant Kubernetes clusters, Windows VM support, built-in VNC console, separate vm-disk / vm-instance resources, persistent worker-node storage for tenant Kubernetes (v1.4), and HAMi-based fractional GPU sharing (v1.4).
• Expanded managed services substantially: added MongoDB, Qdrant, Harbor, OpenBAO, and continued improvements to RabbitMQ, NATS, MariaDB.
• Delivered major storage improvements: LINSTOR scheduler with storage-aware pod placement (v1.3), managed LINSTOR GUI with Keycloak SSO (v1.3), VM Default Images catalog (v1.3), auto-diskful support, tiered storage pools, per-user bucket credentials, read-only S3 access, and object locking.
• Expanded networking capabilities: VPC, multi-location networking based on Kilo / cilium-kilo, topology-aware routing, geo-distributed deployments, ouroboros hairpin-NAT with one-switch PROXY-protocol (v1.4), and tenant-scoped cozy-proxy BPF skip for VM LoadBalancer services.
• Improved tenant isolation, observability, and API maturity: stable per-namespace tenant resource limits, WorkloadsReady / Events observability surface with S3 bucket metering (v1.3), instance-type resource preset taxonomy (v1.4), public REST API and OpenAPI specifications, schema-driven dashboard rewrite talking directly to the Kubernetes API (v1.4).
• Hardened CI/CD security: migrated release workflows from long-lived PATs to short-lived tokens issued by the cozystack-ci GitHub App (v1.3).
• Shipped v1.5 (June 2026): Gateway API ingress backed by Cilium as an opt-in alternative to ingress-nginx; operator-managed TLS for Kafka, NATS, Qdrant, and PostgreSQL endpoints; out-of-the-box backups via a platform-managed default BackupClass with a shared bucket, plus new etcd and generic Job backup strategies; automated GPU passthrough for VMs without manual KubeVirt patching; a flux-shard-operator spreading tenant HelmReleases across helm-controller shards; operator-provided wildcard certificates for platform and root-tenant ingress; a deletion-protection guardrail for critical platform objects; and runtime-populated dashboard dropdowns via a new Option API. Flux was upgraded to v2.8.0 with strict server-side apply and kstatus health checking.
• Kept the platform on current upstream: most recent components include Kubernetes 1.36, Talos v1.13, Cilium v1.19.3, cert-manager v1.20, KubeVirt v1.8.2, NVIDIA GPU Operator v26.3.1, Flux v2.8.0.
• Established a mature release lifecycle: pre-releases, long-lived patch branches, automated backports, and a steady stable + patch cadence.

Required

• Document project goals and objectives that illustrate the project's differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

https://cozystack.io/docs/introduction/

• Document what the project does, and why it does it - including viable cloud native use cases.

https://cozystack.io/docs/introduction/

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

Community Roadmap

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

https://cozystack.io/docs/guides/, https://cozystack.io/docs/guides/use-cases/

• Document the project's release process.

https://cozystack.io/docs/operations/cluster/upgrade/

Security

Suggested

N/A

Required

• Clearly defined and discoverable process to report security issues.

SECURITY.md — published since v1.3.0. Documents private reporting paths, supported version lines, acknowledgement and triage targets (3 / 7 business days), coordinated disclosure model via GitHub Security Advisories, and out-of-scope cases.

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools).

• Organization-wide 2FA enforcement on the cozystack GitHub org

• CODEOWNERS-mandated review for protected paths

• Branch protection on main and release branches (required reviews, status checks)

• Release workflows migrated from long-lived PATs to short-lived tokens issued by the cozystack-ci GitHub App (v1.3.0, PRs [Incubation] Cozystack Incubation Application #1916 (vote closed) #2351, #2383)

• Renovate-managed dependency updates with security alerts

• Document assignment of security response roles and how reports are handled.

SECURITY.md describes the reporting, triage, and coordinated disclosure flow. Coordinated disclosure is performed through GitHub Security Advisories. The most recent example of the process in operation is GHSA-g883-q79m-8225, an unauthenticated information disclosure in the kubeovn-webhook admission handler, triaged and patched in v1.3.3 with a public advisory.

• Document Security Self-Assessment.

In progress. A draft self-assessment is being prepared by the maintainers and will be submitted via PR to cncf/tag-security for a joint assessment with TAG-Security. A copy will be maintained in docs/security/self-assessment.md in the project repository.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

OpenSSF Best Practices: passing, 100% (64/64)

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

ADOPTERS.md

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters.

Cozystack is used in production and development capacities by independent organizations across hosting, cloud, and consulting domains. The public adopter list is in ADOPTERS.md. Verified adopter contacts have been shared privately with the TOC.

• TOC verification of adopters.

Adopter contact details have been shared privately with the TOC for verification. Refer to the Adoption Assertion section of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

Cozystack integrates dozens of CNCF and cloud-native projects as platform building blocks: https://cozystack.io/docs/guides/platform-stack/

Additional Information

This project is important for advancing digital sovereignty, enabling migration from public clouds to bare metal, and equipping local service providers and integrators with an open, free toolkit to compete with hyperscalers (AWS, GCP, Azure) and proprietary platforms (OpenShift, VMware Cloud).