The telco industry is undergoing a fundamental change. Over the past few years, the increasing maturity of cloud-native infrastructure has accelerated the movement from manually operated and hardware-centric systems to automated, software-defined platforms.
Underpinning this change are open source initiatives such as the Sylva project. Sylva is hosted by Linux Foundation Europe and heavily backed by major telecom operators and vendors. It provides a standardized, declarative cloud-native software framework for building and operating telco infrastructures. The project aims to reduce fragmentation in telco clouds and to help telco operators break free from proprietary vendor lock-in.
However, achieving vendor neutrality requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15 years of support longevity, Canonical’s approach to Sylva is built around a requirement that matters deeply to telcos: follow upstream cloud-native innovation when developing and evolving platforms, then rely on long-term support to keep production environments stable, trusted, and operationally predictable.
How does using open source benefit telcos specifically?
Open source architectures serve as engines for accelerated innovation, thanks to global developer ecosystems that collaboratively debug, optimize, and expand software capabilities. Upstream alignment removes proprietary forks and hidden dependencies, giving organizations the flexibility to inspect, modify, and integrate code dynamically.
This is particularly relevant for telcos, which have been historically burdened by rigid, vertically integrated legacy systems and vendor lock-in. In addition, telco networks span highly diverse hardware environments, ranging from centralized core data centers to resource-constrained far-edge cell towers and open RAN distributed units (DUs). As a result, telcos typically face massive capital and operational costs when scaling or updating networks. Moreover, telcos have to navigate a matrix of global and regional regulations, including those around security and data sovereignty. In such complex deployments, even minor software updates or compliance adjustments introduce significant operational overhead.
Open source software allows operators to more easily swap underlying infrastructure blocks, as it provides modular blueprints which enable a composable platform architecture. Likewise, through open source software, prototyping next-generation features is faster due to the global community of developers. Finally, open source software does not require specialized, expensive proprietary hardware and can be deployed directly onto general-purpose hardware which reduces total cost of ownership. These factors mean the open source model reduces time-to-market for new services, simplifies regulatory compliance across fragmented infrastructures, and shifts the industry’s focus from navigating proprietary vendor restrictions to innovating with over-the-top value-added services.
The benefits of using Canonical Kubernetes in Sylva
By using Canonical Kubernetes within Sylva, enterprises benefit from Canonical’s focus on upstream consistency, long lifecycle maintenance, and decoupled architecture. Canonical Kubernetes provides a trusted out of the box approach, while avoiding locking users into a restrictive stack. Instead, the platform remains completely open for downstream customization and architectural extension. This transparency ensures that the underlying infrastructure conforms cleanly to the base Ubuntu Linux layers without hiding behind custom forks or proprietary management wrappers.
The modular architecture of Canonical Kubernetes allows systems to seamlessly align with Sylva’s default cloud-native units. Standard Sylva software units deploy onto Canonical Kubernetes out of the box, without requiring custom application wrappers, keeping the GitOps pipeline clean and predictable. In addition, Canonical Kubernetes natively supports enhanced platform awareness (EPA) features like SR-IOV, DPDK, and PTP synchronization required for 5G without needing proprietary operators. This decoupled, modular architecture allows operators to scale efficiently from raw hardware to complex 5G application workflows.
Because telco environments often demand unique customizations, Canonical directly supports customers through this integration process, as demonstrated by its contributions within Sylva. For telcos requiring custom component tailoring or specific upstream modifications, Canonical can extend this support through its large open source software catalog of containers. This ensures that customized telco containers are built, validated, and maintained with the same strict trusted, regulatory and operational principles as the core distribution itself.
The principles of improved operational predictability and reduced risk also apply beyond initial integration. Telcos need platforms that can be adapted to their network requirements, then operated safely for many years. Their clouds are built to match long physical infrastructure lifespans, not rapid upstream software deprecation cycles. Canonical offers up to 15 years of Long Term Support (LTS) for its Kubernetes distributions via Ubuntu Pro. This long-term stability is a particular benefit to telcos, where upgrading core networks (like 5G Core or O-RAN) carries massive operational risk. LTS Kubernetes enables operators to build once and receive maintenance for a longer operational window, without undergoing forced, disruptive platform migrations. This offers telcos a stable platform foundation that frees engineering teams from recurring upgrade cycles, allowing them to focus on upper-layer network application performance.
Declarative cluster lifecycle management with Canonical Kubernetes
While the telco ecosystem agrees on the necessity of cloud-native standardization, the way Kubernetes platforms are packaged and operated can either reinforce or weaken Sylva’s open model. Approaches that rely on highly integrated, specialized platform stacks or heavily modified Kubernetes distributions may end up tying cluster functionality to proprietary management utilities and tightly coupled operating system dependencies. While this may offer a high degree of curation out of the box, the underlying infrastructure becomes highly opinionated, introducing an architectural paradox for telcos seeking greater vendor neutrality. Over time, this subtly introduces a new form of platform-specific lock-in, restricting an operator’s ability to swap out software components or straightforwardly migrate workloads to alternate infrastructures.
Canonical offers a different approach. By aligning with Sylva’s open infrastructure standards, Canonical Kubernetes allows Sylva’s declarative model to operate without an additional proprietary control layer.
Within a Sylva-managed telco cloud, Cluster API (CAPI) and FluxCD provide the declarative lifecycle and GitOps control framework used to orchestrate management and workload clusters. Cluster definitions, infrastructure provider selections, and platform configuration are maintained declaratively in Git through the sylva-units deployment model, which generates FluxCD Kustomizations and HelmReleases to orchestrate platform components and dependencies. FluxCD continuously reconciles the desired state from Git into the management cluster, where Cluster API controllers interpret the resulting custom resources and coordinate cluster provisioning, scaling, upgrades, and remediation workflows.
To execute these declarative specifications natively without the abstraction layers that typically drive vendor lock-in, CAPI coordinates the deployment across multiple provider layers. Sylva integrates CAPI providers (such as the CAPI bootstrap provider for Canonical Kubernetes and the Canonical Kubernetes control plane provider) to translate high-level CAPI specifications into Canonical Kubernetes node and control-plane configurations. These providers automate node bootstrap, control-plane initialization, and cluster joining using Canonical Kubernetes installation and configuration mechanisms, including snap-based package delivery where applicable. Once operational, Canonical Kubernetes clusters remain under continuous reconciliation through FluxCD and Cluster API control loops, enabling declarative upgrades, configuration drift correction, and infrastructure remediation workflows.
Conclusion
Project Sylva standardizes how telco clouds are built using open, non-fragmented declarative blueprints. The integration of Canonical Kubernetes demonstrates that open standards can be maintained without adding heavy, opinionated software bundles.
However, in an industry where upgrading a core network runtime carries significant operational and compliance risks, frequent forced updates present a major vulnerability. Canonical delivers a clean separation of concerns, while supporting the footprint with long-term maintenance through Ubuntu Pro. Further, through custom integration support and thanks to our extensive LTS open source software catalog, Canonical ensures that telcos can customize, validate, and maintain their specific runtime components within a trusted framework over these extended lifecycles. With Canonical, telcos can deploy for Day 1, operate for the long run, and keep their network future open.
Next steps
Learn how Canonical solutions provide a stable, validated, and open foundation for telco workloads.