Telecom operators in 2026 face an architectural inflection point: legacy NFV environments aging out, edge-compute demands growing, sovereign-cloud branded products launching across the sector, AI workloads on customer data, and NIS2 essential-entity compliance. The architectural answer is a coherent platform that runs at core data centres, regional sites, and customer edge — under one operations model.
Ænix builds platforms for telecom operators across the EU, DACH, and Central Asia. Same platform, Cozystack, at core and edge. AENIX s.r.o. holds ISO/IEC 27001:2022 certification for its own ISMS; cloud leads can start with the head of cloud guide.
Pairs with: Ænix Public Cloud Platform for telcos launching customer-facing sovereign cloud products at multi-region scale; Private Cloud Platform for NIS2-aligned internal cloud and edge platforms.
What telecom operators come to us for
- Sovereign cloud product launches — operators offering customer-facing sovereign cloud (regional telco sovereign cloud products, member-state-specific sovereign products). See Data sovereignty.
- NFV → Kubernetes platform transitions — legacy NFV environments replaced with Kubernetes-native equivalents.
- Edge cloud at scale — central core + regional + customer-edge sites under unified operations.
- Sovereign AI infrastructure — telco-data analytics, customer-care AI, network-ops AI.
- NIS2 compliance — telecom is an essential entity under NIS2.
- Hyperscaler exit — sustained workloads where economics no longer fit.
Why telco architecture is different
- Multi-site operations — core DC + regional sites + edge sites + customer-premises equipment, under one platform abstraction.
- 5G + AI convergence — network slicing, MEC, and AI inference at edge.
- Regulatory complexity — NIS2 essential-entity, sectoral telco regulators, sovereignty mandates per jurisdiction.
- Customer-facing offers — many telcos resell platform capability to enterprise customers; multi-tenant customer-facing model is structural.
- Long depreciation cycles — hardware refresh cycles longer than typical enterprise; platform must work on multiple hardware generations.
The dataplane question
Everything above is true of any distributed estate. What makes telco different is that a share of the workload does not tolerate a generic Kubernetes dataplane, and a platform that cannot say how it handles that is not a telco platform.
- SR-IOV and device passthrough. Packet-processing functions want a VF bound directly to the workload, not a veth pair. Cozystack supports SR-IOV virtual functions and PCI passthrough into KubeVirt VMs, so a VNF that was certified on a VF keeps its VF. Where a function needs a whole NIC or an accelerator, it gets one.
- DPDK and userspace networking. Functions built on DPDK bypass the kernel network stack entirely; they need hugepages, CPU pinning, isolated cores and a NUMA-aware placement, not a best-effort scheduler slot. Those are node-level and pod-level settings on the platform, applied per workload class rather than cluster-wide, so a DPDK function and an ordinary microservice share a cluster without either compromising.
- CNFs and the VNFs that are not ready to become CNFs. Vendor network functions arrive as VMs with a support matrix, and the transition to containers happens on the vendor’s schedule, not yours. Both run side by side on one platform: KubeVirt for the VM-packaged functions, containers for the cloud-native ones, one API, one lifecycle, one observability stack.
- Cilium and eBPF for everything else. Management, OSS/BSS, customer-facing services and MEC applications run on the eBPF dataplane, with network policy and observability that do not require a sidecar per pod.
The honest boundary: this is a platform for the estate around the network — MEC, edge applications, OSS/BSS, customer-facing cloud, AI inference, and the VNFs that live in a data centre. It is not a claim to replace a purpose-built packet core.
How Ænix engages with telecom operators
Standard Platform Readiness Assessment with telecom-specific workstreams: multi-site architecture, edge readiness, sovereign-cloud product packaging (where applicable), NIS2 controls, AI infrastructure for telco use cases.
Multi-site programmes typically run a 3–6 month pilot, then 9–18 months to a full multi-site rollout.
Companies running platforms built with Ænix
Hosting providers running Ænix Public Cloud Platform in production
Hosting providers running Ænix Public Cloud Platform in production.
Telecom customers are not named. The closest written-up case is a telecom operator and integrator that built a corporate AI platform on Cozystack.
Why Ænix specifically for telecom
- Edge-to-core platform. One Cozystack operational model for core data centres, regional sites, and edge.
- Multi-tenant customer-facing model — Tenant CRD designed for service-provider model, suitable for telco customer-facing cloud products.
- Open-source foundation — Apache 2.0 platform; no per-CPU pricing, no vendor lock-in across hardware refresh cycles.
- Sovereignty-aligned — air-gapped installs, opt-in volume encryption, audit logs for NIS2 evidence.
- EU + Central Asia teams. Engineering teams in the EU and Central Asia; EU contracts through AENIX s.r.o. (Czech Republic).
How to start
- Sovereign AI — telecom AI use cases
- Data sovereignty — telco regulatory trigger
- Private cloud consulting — broader scope
- Platform Readiness Assessment
- Cozystack
- Head of cloud guide
Ænix created Cozystack (CNCF Sandbox project, CNCF Certified Kubernetes distribution) and co-maintains it with maintainers from other companies. On top of it we offer three platforms — Public Cloud, Private Cloud and AI.




