Component facts below reflect the Cozystack v1.6 release line (current as of September 2026).
Cozystack is an open-source cloud platform — Apache 2.0 licensed, CNCF Project, built primarily by Ænix with growing community contribution. It started as an internal platform for service-provider customers and was open-sourced in 2023 because the architectural pattern proved generally useful.
What Cozystack is, technically
A single Kubernetes-based platform that runs on bare metal and provides:
- KubeVirt-based virtualization (VMs alongside containers)
- Multi-tenant control plane via Tenant CRD
- Managed database, queue, cache services
- S3-compatible object storage
- GPU as a service (VFIO passthrough or NVIDIA vGPU for VMs; HAMi fractional sharing for containers in tenant Kubernetes clusters)
- Self-service portal (Cozystack Dashboard)
- Observability (VictoriaMetrics + VictoriaLogs)
- Backup and DR (Velero + per-app PITR)
- WHMCS billing integration for the service-provider model (an Ænix product on top of Cozystack, not an upstream component)
All controlled by a cohesive operational model — single platform team running one stack rather than integrating ten.
Architectural choices and why
Choice 1: KubeVirt for virtualization
KubeVirt runs VMs as Kubernetes resources. Pods that wrap qemu/KVM, with all the Kubernetes ecosystem benefits — declarative config, GitOps, observability, RBAC, networking integration — extending to VMs naturally.
The alternative would be a parallel virtualization stack (libvirt directly, OpenStack, vendor hypervisor). KubeVirt unifies; alternatives fragment.
Choice 2: Talos Linux as the OS
Talos is a minimal, immutable Linux designed for Kubernetes. No SSH; configuration via API; no package manager; no shell. Operationally simpler and more secure than general-purpose Linux for Kubernetes hosts.
Talos is the default, not a requirement. Since Cozystack v1.0 the platform also installs onto an existing Kubernetes cluster running a general-purpose distribution (Ubuntu, Debian, RHEL-family, openSUSE) via the isp-full-generic variant or the cozystack.installer Ansible collection.
Choice 3: LINSTOR as default storage
LINSTOR (DRBD-based, deployed through the Piraeus operator) provides replicated block storage with good operational characteristics for Kubernetes. It remains the shipped default through the v1.6 release line. Object storage is a separate layer — SeaweedFS, exposed as the managed Bucket service. Cozystack does not ship Rook or Ceph. Ænix is building Blockstor, a Kubernetes-native, LINSTOR-API-compatible control plane for LVM/ZFS with DRBD replication; it is not yet part of a Cozystack release.
Choice 4: Cilium for networking
eBPF-based networking with native L4/L7 policies, observability, and service-mesh capabilities. Replaces what NSX did in VMware deployments without licensing.
Choice 5: Tenant CRD for multi-tenancy
Native Kubernetes resource defining tenant boundaries. Nested tenants for resellers / business units. Per-tenant quotas, RBAC, audit trail. Service-provider model is structural rather than bolted-on.
Choice 6: Flux for GitOps
Lightweight, upstream-Kubernetes-aligned GitOps engine. Flux is the platform’s own reconciliation engine (v2.8 as of Cozystack v1.6). You can point Argo CD at your Cozystack manifests like any other Kubernetes resources, but Argo CD as an alternative platform engine is still a roadmap item, not a supported install path.
Choice 7: VictoriaMetrics + VictoriaLogs for observability
Lower-overhead than Prometheus + Loki at scale. Important for sovereignty (self-hosted, no SaaS observability dependency).
How Cozystack compares
Cozystack vs OpenStack
Both open source. Both private cloud platforms. Different generations.
OpenStack: 2010s-era architecture. Comprehensive but operationally heavy. Strong in telco / large government use cases. Operational footprint: 50-100+ services, distinct teams maintaining each component.
Cozystack: 2020s-era architecture. Kubernetes-native. Single platform abstraction. Operational footprint: 5-15 components running as Kubernetes operators, single platform team.
For new deployments in 2026, Cozystack is increasingly the default. For existing OpenStack deployments where operational expertise lives, OpenStack remains valid.
Cozystack vs OpenShift Virtualization
Both KubeVirt-based.
OpenShift Virtualization: Red Hat commercial subscription. Strong enterprise tooling. Tied to Red Hat / IBM relationship.
Cozystack: Apache 2.0 open source. Ænix commercial support optional. Lighter operational footprint without the OpenShift surface area.
For Red Hat customers, OpenShift Virtualization fits naturally. For organizations preferring open-source-first, Cozystack.
Cozystack vs Proxmox VE
Both open source. Different scales.
Proxmox: SMB-friendly, single-tenant, mature. Excellent under ~50 hosts.
Cozystack: Multi-tenant scale, service-provider-friendly. Better above ~50 hosts and where multi-tenancy matters.
The Ænix relationship
Cozystack and Ænix are intentionally separate:
- Cozystack is community-governed CNCF Project. Apache 2.0. Anyone can deploy, contribute, or fork.
- Ænix is the commercial entity. Builds and maintains Cozystack. Provides paid support tiers and professional services.
The separation matters because:
- Customer choice — you can deploy Cozystack independently. You don’t need Ænix to use the platform.
- Project longevity — Cozystack survives Ænix-business decisions because it’s CNCF-governed and Apache-licensed.
- Ænix focus — Ænix sells engagement (assessment, build, support), not licenses.
For organizations seeking commercial support, Ænix is one option (the primary one in 2026 because Ænix is the largest contributor). Other commercial support providers may emerge as the project matures.
When Cozystack is the right answer
- Service-provider model — multi-customer cloud, billing, customer-facing portal
- Regulated multi-tenant — banks, insurers, public sector
- AI/GPU at scale — sustained workloads, sovereignty for data residency
- Greenfield private cloud — new infrastructure, modern architecture
- VMware exit — Cozystack as destination for KubeVirt-based migration
When Cozystack is not the right answer
- Single-tenant SMB — Proxmox VE is operationally simpler
- Existing deep OpenStack expertise — extending OpenStack may be cheaper than migrating
- Existing Red Hat / OpenShift — OpenShift Virtualization fits the procurement and team familiarity
- Pure container workloads (no VMs) — vanilla Kubernetes is sufficient
- Pure public-cloud-native architecture — hyperscaler-managed services may be the right call
A good engagement is honest about these cases.
Test yourself: what Cozystack is
5 questions · ~2 min