Broadcom Contributes Velero, Its Kubernetes-Native Backup Solution, to CNCF Sandbox

Broadcom has officially announced the contribution of Velero, its widely-adopted Kubernetes-native backup, restore, and migration project, to the Cloud Native Computing Foundation (CNCF) as a Sandbox project. This significant move, unveiled at KubeCon + CloudNativeCon Europe 2026 in Amsterdam, marks a pivotal moment for the project, relocating it to a vendor-neutral home within the vibrant cloud-native ecosystem. Velero distinguishes itself by operating at the Kubernetes API layer, meticulously capturing cluster state through Custom Resource Definitions (CRDs) rather than relying on hypervisor or storage-layer snapshots, offering a more granular and Kubernetes-centric approach to data protection.
Velero’s Genesis and Technical Prowess
Velero’s journey began with Heptio, the influential Kubernetes company founded by former Google engineers Joe Beda and Craig McLuckie. Heptio, a key player in advancing Kubernetes adoption and tooling, was acquired by VMware in 2019. Since then, Velero has been under VMware’s stewardship, and subsequently, Broadcom’s, following its acquisition of VMware in 2023. This long lineage under enterprise giants underscores its maturity and robustness, cultivated through years of development and real-world application.
At its core, Velero empowers platform teams to ensure the resilience and portability of their Kubernetes workloads. It facilitates the backup of critical components such as namespace definitions, persistent volume claims (PVCs), Role-Based Access Control (RBAC) policies, and various other resource configurations. These elements are captured as portable Kubernetes objects, which can theoretically be restored to a different cluster or even an entirely distinct Kubernetes distribution from the one where the backup originated. This inherent portability is a cornerstone of its utility in disaster recovery, cluster migration, and development environment replication scenarios. Its widespread adoption is reflected in its impressive GitHub presence, boasting nearly 9,900 stars, indicating a strong community interest and active usage base.
The Significance of CNCF Sandbox Inclusion
The Cloud Native Computing Foundation serves as the primary vendor-neutral home for many of the fastest-growing open-source projects, including Kubernetes itself. Its mission is to make cloud-native computing ubiquitous, providing governance, infrastructure, and community support for a vast array of technologies. The Sandbox stage is the entry point for promising projects into the CNCF landscape. It signifies that a project has garnered initial interest, shows potential for broader community engagement, and aligns with the CNCF’s mission, but requires further nurturing and development within the foundation’s framework. Projects typically progress through Incubation and eventually Graduation stages as they mature, demonstrate significant adoption, and establish robust governance.
Chris Aniszczyk, CTO of the CNCF, underscored the importance of Velero’s contribution, stating, "As organisations scale their cloud native workloads, the focus is shifting from simple orchestration to long-term resilience and data management. Velero provides a vital layer for backup and disaster recovery, ensuring that stateful applications remain protected. By joining the CNCF Sandbox, Velero gains a vendor-neutral home to foster community collaboration and growth." This sentiment highlights the critical need for reliable data management solutions as enterprises increasingly rely on Kubernetes for their most critical applications. The move provides Velero with enhanced visibility, broader community contributions, and a clear, vendor-agnostic governance model, which are crucial for long-term sustainability and widespread enterprise adoption.
Broadcom’s Strategic Rationale: Investment, Not Divestiture
Dilpreet Bindra, Senior Director of Engineering for the VCF Division at Broadcom, clarified the company’s perspective on the contribution during KubeCon. He firmly stated that Broadcom views this move as an "investment rather than a divestiture." Bindra articulated, "We’re not just users of Kubernetes, we’re builders, and we make Kubernetes easier to run, not harder." This statement aims to position Broadcom as a committed contributor to the open-source ecosystem, particularly in the cloud-native space.
Bindra also candidly addressed the "trust dimension" surrounding the decision. In a post-conference interview, he acknowledged that some observers might interpret the contribution as Broadcom disengaging from a project it no longer valued. He directly pushed back against this interpretation, asserting Broadcom’s continued commitment: "It is a tool that we believe in our overall VKS story as well as our overall IaaS story is going to have huge dividends that we’re going to keep investing in." This indicates that Velero remains an integral part of Broadcom’s broader strategy, likely referring to its VMware Kubernetes Service (VKS) offerings and its foundational Infrastructure-as-a-Service (IaaS) solutions, reinforcing the company’s intent to continue investing resources into the project’s development and evolution.
This strategic move by Broadcom aligns with a broader pattern of contributing to the open-source community. The VMware blog post announcing the Velero contribution also detailed parallel work with the etcd contributor community, focusing on diagnosis and recovery tooling, published on GitHub as github.com/vmware/etcd-diagnosis and github.com/vmware/etcd-recovery. These tools are designed to provide Kubernetes operators with improved visibility into control-plane health and simpler recovery paths from failures, addressing critical operational challenges. Furthermore, Broadcom emphasized continued collaboration with the Cluster API (CAPI) community, focusing on cluster provisioning, upgrade orchestration, and node lifecycle management. RedMonk analyst James Governor, in a recorded conversation with Bindra and Zach Shepherd at KubeCon, notably described Broadcom’s sustained contributions to the CNCF as "probably the best kept secret in the industry," highlighting a consistent, albeit less publicized, commitment to open source.
Community and Industry Reception: Overwhelmingly Positive
The community response to Broadcom’s announcement was overwhelmingly positive, echoing sentiments of validation and relief across the cloud-native landscape. Orlin Vasilev, a respected CNCF Ambassador and a former Velero contributor and community manager, expressed his enthusiasm on LinkedIn, noting, "That took ‘few’ years to be seen as (the) next logical step, but still it’s happening… Sooo happy to see that as ex-contributor and community manager for Velero, this is HUGE!" His reaction captures the long-held desire within the community for Velero to find a vendor-neutral home, ensuring its longevity and broad adoption without the perceived constraints of single-vendor ownership.

Shubham Pampattiwar, a Red Hat engineer and one of the maintainers who co-submitted the sandbox application, had already posted on LinkedIn about the proposal in February, indicating the meticulous preparation and cross-vendor collaboration that preceded the official announcement. This collaborative effort among maintainers from different organizations signals a healthy, multi-vendor commitment to Velero’s future. The DevTools Radio podcast, in an episode published after KubeCon, characterized the community response to the donation as "overwhelmingly positive" and a resounding "yeah, this makes complete sense," echoing Bindra’s own assessment of the reception.
The Rack2Cloud architecture blog published a detailed analysis shortly after KubeCon, framing the governance change as much about "trust repair" as it is about the mechanics of open source. The analysis noted that Broadcom’s internal framing at the conference, particularly a comment about not wanting users to regard Velero as "a VMware thing," clearly signaled that a primary audience for the CNCF move was organizations that had previously hesitated to standardize on Velero precisely due to its single-vendor lineage. This perspective highlights the critical role of vendor neutrality in fostering widespread enterprise adoption, especially for foundational infrastructure tools. The blog post drew a careful distinction between vendor-neutral governance, which the CNCF effectively provides, and vendor-independent operations, which it does not directly influence. Velero’s runtime dependencies on external object storage, IAM credential chains, and a functioning target cluster remain unchanged by the governance transition, underscoring that while governance has shifted, the operational realities and engineering responsibilities for users remain consistent.
Governance and the Evolving Maintainer Landscape
The current maintainer list for Velero already reflects a multi-vendor commitment, including representatives from Broadcom, Red Hat, and Microsoft. Furthermore, the project’s existing governance model has proactively incorporated CNCF-aligned principles, such as consensus-based decision-making with supermajority voting and a five-day lazy-consensus review period, as reported by Machine Herald. This pre-existing alignment should facilitate a smoother transition into the CNCF’s governance framework.
However, Machine Herald also raised an important open question: whether the composition of the maintainer community will shift significantly as community governance fully takes hold, and whether the project, given its extensive production adoption, will move quickly through incubation toward CNCF graduation. The answers to these questions will be critical in shaping Velero’s future trajectory, potentially bringing in new contributors and accelerating its development under a broader, more diverse maintainer base.
Technical Implications and Future Roadmap
The Velero project joins a comprehensive CNCF portfolio that already includes several data-plane and observability tools crucial for robust Kubernetes operations. The CNCF itself has previously published guidance on Kubernetes backup and migration strategies utilizing Velero, predating this governance change and detailing how the project facilitates cluster migration across various providers.
Velero’s core operational design is elegantly simple yet powerful: it treats object storage as its primary source of truth. It continuously reconciles backup resources within the cluster against the contents of the configured storage bucket. This architectural choice means that a backup taken on one cluster can be readily discovered and restored by a Velero installation on an entirely different cluster, provided that the new cluster has access to the same storage location. This property is fundamental to its utility in complex workload migration scenarios and multi-cloud strategies.
Looking ahead, the techbytes.app analysis of the announcement suggests several potential directions for Velero’s roadmap, which will now be shaped by the broader maintainer community rather than Broadcom alone. These anticipated developments include the potential for a centralized control plane designed for managing backup policies across multiple Kubernetes clusters, significantly enhancing operational efficiency for large-scale deployments. Improved integration with the Container Storage Interface (CSI) Data Management specification is also envisioned, which would enable more sophisticated application-aware backups, including pre-snapshot quiescing to ensure data consistency for stateful applications. Additionally, the adoption of Sigstore for signing backup artifacts could introduce enhanced security and integrity verification for Velero backups. While these are described as anticipated directions rather than confirmed commitments, they illustrate the exciting potential for Velero’s evolution under its new, more expansive governance.
Broader Impact and Strategic Outlook
For platform teams evaluating this change, the Rack2Cloud article offers a pragmatic perspective: organizations that previously hesitated to standardize on Velero due to its perceived VMware lineage now have a significant governance argument removed. The move to CNCF effectively neutralizes concerns about single-vendor lock-in or the potential for a project to be deprioritized by a corporate entity. This provides a renewed level of assurance regarding the project’s long-term viability and community-driven development.
However, it is equally important for these teams to recognize that the fundamental operational architecture of Velero remains unchanged. The dependencies on reachable external object storage, valid IAM credentials for accessing that storage, and a functioning restore target cluster are the same as they were before the announcement. These elements continue to require the same diligent engineering attention and operational expertise, regardless of which entity governs the project. The transition primarily addresses governance and trust, not the underlying operational requirements.
Ultimately, Broadcom’s contribution of Velero to the CNCF Sandbox is a multifaceted move with significant implications. For Velero, it promises accelerated development, broader community engagement, and a clear path toward becoming an even more indispensable tool in the cloud-native toolkit. For Broadcom, it represents a strategic investment in its open-source credibility and its commitment to the Kubernetes ecosystem, aligning with its narrative as a "builder" and not just a "user." For the wider cloud-native community, it solidifies the availability of a critical data protection solution under a vendor-neutral umbrella, fostering greater trust, collaboration, and innovation in the ever-evolving landscape of Kubernetes.







