Broadcom has announced the contribution of Velero, its Kubernetes-native backup, restore and migration project, to the Cloud Native Computing Foundation (CNCF) as a Sandbox project. Velero It operates at the Kubernetes API layer, capturing cluster state through Custom Resource Definitions (CRDs) rather than through hypervisor or storage-layer snapshots. The announcement was made at KubeCon + CloudNativeCon Europe 2026 in Amsterdam.
Velero traces its origins to Heptio, the Kubernetes company founded by former Google engineers Joe Beda and Craig McLuckie, which VMware acquired in 2019. The project has been under VMware and subsequently Broadcom stewardship since then. Platform teams use it to back up namespace definitions, persistent volume claims, RBAC policies, and other resource configurations as portable Kubernetes objects that can, in theory, be restored to a different cluster or distribution than the one from which the backup was taken. It has nearly 9,900 stars on GitHub.
"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."
-- Chris Aniszczyk, CTO, CNCF
Dilpreet Bindra, Senior Director of Engineering for the VCF Division at Broadcom, stated at KubeCon that the company sees the contribution as an investment rather than a divestiture: "We're not just users of Kubernetes, we're builders, and we make Kubernetes easier to run, not harder." Bindra has also been candid about the trust dimension of the move. In an interview with Pete Flecha and John Nicholson following the conference, he acknowledged that some observers might read the contribution as Broadcom walking away from a project it no longer believed in, and pushed back directly on that reading, saying Velero is a tool the company intends to keep investing in as part of its VKS and IaaS story.
The Rack2Cloud architecture blog published a detailed analysis of the announcement shortly after KubeCon, arguing that the governance change is as much about trust repair as about open source mechanics. The piece notes that Broadcom's own framing at the conference, specifically a comment about not wanting users to regard Velero as "a VMware thing," signals that the primary audience for the CNCF move is organisations that had hesitated to standardise on Velero precisely because of its single-vendor lineage. The blog draws a careful distinction between vendor-neutral governance, which CNCF provides, and vendor-independent operations, which it does not. Velero's runtime dependencies on external object storage, IAM credential chains and a functioning target cluster are unchanged by the governance transition.
"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."
-- Dilpreet Bindra, Senior Director of Engineering, VMware Cloud Foundation Division, Broadcom
The current maintainer list includes Broadcom, Red Hat and Microsoft, and the project's existing governance model already incorporates CNCF-aligned principles, including consensus-based decision-making with supermajority voting and a five-day lazy-consensus review period, according to Machine Herald. One open question noted by Machine Herald is whether the maintainer composition will shift as community governance takes hold, and whether the project will move quickly through incubation toward CNCF graduation, given its extensive production adoption.
The community response to the announcement was broadly positive. Orlin Vasilev, a CNCF Ambassador and former Velero contributor and community manager, wrote on LinkedIn: "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!" Red Hat engineer Shubham Pampattiwar, one of the maintainers who co-submitted the sandbox application, also posted on LinkedIn about the proposal in February. In a DevTools Radio podcast episode published after KubeCon, hosts described the community response when the donation was announced as "overwhelmingly positive" and resounding "yeah, this makes complete sense," citing Bindra's own characterisation of the reception.
The Velero move was announced alongside several other Broadcom upstream contributions. The VMware blog post describes parallel work with the etcd contributor community on diagnosis and recovery tooling, published at github.com/vmware/etcd-diagnosis and github.com/vmware/etcd-recovery, intended to give Kubernetes operators better visibility into control-plane health and simpler recovery paths from failures. Broadcom also notes continued collaboration with the Cluster API (CAPI) community on cluster provisioning, upgrade orchestration and node lifecycle management. RedMonk analyst James Governor, in a recorded conversation with Bindra and Zach Shepherd at KubeCon, described Broadcom's sustained contributions to the CNCF as "probably the best kept secret in the industry."
The Velero project joins a CNCF portfolio that already includes several data-plane and observability tools relevant to Kubernetes operations. The CNCF has published guidance on Kubernetes backup and migration strategies using Velero that predates this governance change and covers how the project handles cluster migration across providers. The Velero documentation explains that the project treats object storage as the source of truth, continuously reconciling backup resources in the cluster against the contents of the configured storage bucket. This design means a backup taken on one cluster can be discovered and restored by a Velero installation on a different cluster, provided it has access to the same storage location; a property that is central to its use in workload migration scenarios.
The techbytes.app analysis of the announcement suggests that the project's roadmap may eventually include a centralised control plane for managing backup policies across multiple clusters, improved integration with the CSI Data Management spec to support application-aware backups with pre-snapshot quiescing, and signed backup artefacts using Sigstore. These are described as anticipated directions rather than confirmed commitments, and it is worth noting that the project's near-term roadmap will now be shaped by the broader maintainer community rather than by Broadcom alone.
For platform teams evaluating the change, the Rack2Cloud article offers another perspective: organisations that previously avoided standardising on Velero because of its VMware lineage now have a legitimate governance argument removed. The operational architecture (the dependencies on reachable external object storage, valid IAM credentials, and a functioning restore target) is the same as before the announcement and requires the same engineering attention regardless of who governs the project.