Velero Joins CNCF Sandbox: Community Governance for Kubernetes Backup

Velero, a Kubernetes-native tool for backup, restore, and migration, has been contributed by Broadcom to the Cloud Native Computing Foundation (CNCF) as a Sandbox project. This transition shifts governance from a single vendor to the open-source community. Below are common questions answered about this move and Velero's capabilities.

What is Velero and what does it do?

Velero is an open-source tool designed specifically for Kubernetes environments. It handles backup, restore, and migration of cluster resources and persistent volumes. Unlike traditional backup tools that rely on hypervisor or storage-level snapshots, Velero operates directly at the Kubernetes API layer. It uses Custom Resource Definitions (CRDs) to capture the entire cluster state, including deployments, services, and configurations. This makes it deeply integrated with Kubernetes workflows. Velero also supports scheduled backups and can restore resources to a different cluster if needed, enabling straightforward disaster recovery and cluster migration scenarios. By focusing on the API layer, it ensures that backups are portable across different infrastructures and cloud providers.

Why did Broadcom donate Velero to the CNCF?

Broadcom, which acquired Velero through its purchase of VMware, decided to donate the project to the CNCF to foster broader adoption and community-driven development. Placing Velero under a neutral foundation like CNCF ensures that its evolution is guided by a diverse set of contributors rather than a single corporate roadmap. This move aligns with the cloud native ecosystem's preference for open governance. It also provides enterprises with confidence that the tool will remain independent and continue to receive contributions from multiple stakeholders. By becoming a CNCF Sandbox project, Velero gains visibility and credibility within the Kubernetes community, and it can more easily attract new maintainers and users who value community-led innovation.

What is the significance of Velero becoming a CNCF Sandbox project?

CNCF Sandbox is the entry-level stage for projects hosted by the foundation. It indicates that the project is early-stage but has potential for growth and adoption. For Velero, this means it now benefits from CNCF's intellectual property protection, trademark management, and community guidelines. It also gains access to a larger ecosystem of cloud native tools and a formal process for becoming a more mature project (graduating to Incubation and then to Graduated status). This sandbox phase encourages experimentation and community feedback without heavy pressure to meet rigorous maturity criteria immediately. For users, the Sandbox label signals that the project is being vetted and supported by the foundation, though it may still undergo significant changes. Ultimately, it positions Velero as a credible option for Kubernetes backup under neutral governance.

How does Velero differ from traditional backup solutions for Kubernetes?

Traditional backup solutions often operate at the hypervisor or storage system level, capturing entire virtual machine disks or file system snapshots. While effective for VMs, this approach doesn't align with Kubernetes' stateless and ephemeral nature. Velero, in contrast, works at the Kubernetes API layer. It uses Custom Resource Definitions (CRDs) to define backup and restore operations, allowing it to capture not just persistent volume data but also the entire cluster configuration including namespaces, deployments, and custom resources. This API-level approach makes Velero more portable across different Kubernetes distributions and cloud providers. It also enables fine-grained selective backups and integrates with Kubernetes-native scheduling tools. By avoiding reliance on infrastructure-specific snapshots, Velero ensures that backups are consistent and can be restored even in completely different environments.

What are Custom Resource Definitions (CRDs) and how does Velero use them?

Custom Resource Definitions (CRDs) are a powerful extension mechanism in Kubernetes that allow you to define your own resource types. Velero uses CRDs to create custom objects that represent backup, restore, and schedule operations. For instance, when you install Velero, it creates a Backup CRD. When you initiate a backup, Velero generates an instance of this CRD that contains metadata about the backup job, such as the resources to include and storage location. This CRD instance is stored in the cluster's etcd database, making Velero's operation fully declarative and Kubernetes-native. CRDs also enable Velero to extend its functionality through plugins and custom hooks. By leveraging CRDs, Velero integrates seamlessly with Kubernetes workflows, allowing users to manage backups using the same kubectl commands they use for other resources.

What are the next steps for Velero under CNCF governance?

As a Sandbox project, Velero will now undergo CNCF's community onboarding process. This includes establishing a clear governance model, adopting CNCF's code of conduct, and building a diverse maintainer team beyond Broadcom engineers. The community will define the project's roadmap through open discussions. Technical improvements such as enhanced support for large-scale clusters, more robust backup validation, and integration with other CNCF projects (like Prometheus or Knative) are likely. Broadcom will remain a key contributor, but the goal is to reduce bus factor and encourage external contributions. To graduate to Incubation stage, Velero must demonstrate a healthy community with multiple contributors, a documented governance process, and successful usage in production environments. Users can expect more frequent releases and a clearer contribution guide as the project matures.

How does Velero handle backup and restore at the Kubernetes API layer?

Velero interacts directly with the Kubernetes API server to list all resources in a cluster (or a subset defined by label selectors). It then serializes those resources into backup files (typically stored in cloud object storage like S3, GCS, or Azure Blob). For persistent volumes, Velero can trigger snapshots via cloud provider APIs or use a file-level backup plugin. The restore process reverses this: it reads the backup files, creates the necessary Kubernetes resources in the target cluster, and attaches persistent volumes from snapshots. Because it works at the API layer, Velero does not require agent installation in pods or special hypervisor access. It only needs a service account with appropriate RBAC permissions. This architecture makes Velero lightweight and cluster‑agnostic, yet powerful enough to handle complex workloads. It also supports selective restoration of specific resources or namespaces.