Velero

What it is

Velero is a backup, restore, and disaster recovery tool for Kubernetes clusters. It snapshots cluster resources (via the Kubernetes API) and persistent volume data (via CSI snapshots or its own volume plugins), then lets you restore them to the same cluster or migrate them to a different one. It runs as an in-cluster controller plus a CLI, and it's commonly used for etcd-independent backup, namespace migration, and cluster-to-cluster moves during upgrades or cloud migrations.

Who builds it and why

Velero was originally built by Heptio (Ark), acquired by VMware in 2018, and has since lived under VMware/Broadcom's Tanzu portfolio. It sits in CNCF Sandbox, not Incubating or Graduated — worth noting given how widely it's deployed in production. Despite sandbox status, it has 403 contributors and an active commit history, suggesting real engineering investment beyond a single vendor's marketing needs. VMware's motivation is straightforward: Velero backstops their Tanzu platform story and gives them a foothold in every cluster that installs it, open source or not.

Production readiness signal

• 10,097 GitHub stars, 403 contributors — broad adoption and a large enough contributor base that it's not a single-maintainer bus-factor risk.
• Active commit cadence through mid-2026 indicates the project is not abandoned.
• Latest release v1.18.2 — a mature version number suggesting years of iteration, though check the changelog for breaking changes between major CSI/plugin API versions before upgrading.
• CNCF Sandbox maturity is the caution flag here: it means the CNCF hasn't formally vetted Velero's governance, security practices, or multi-vendor neutrality to Incubating standards. In practice, most production users treat it as de facto standard anyway — but don't assume CNCF sandbox equals "battle-tested" on paper.
• Apache-2.0, Go — standard, unencumbered licensing.

Who should use this

• Teams needing namespace or full-cluster backup/restore that isn't tied to a specific storage vendor's snapshot tooling.
• Anyone doing cluster migrations (cloud-to-cloud, on-prem-to-cloud, or version upgrades requiring blue/green clusters).
• Platform teams standardizing DR across multiple clusters where a CLI + CRD-based workflow fits GitOps pipelines.
• Organizations already on Tanzu, where Velero integration is native and well-supported commercially.

Who should NOT use this

• Teams needing point-in-time application-consistent backups for stateful databases beyond what pre/post hooks provide — Velero's hooks are basic; dedicated DB backup tools (pgBackRest, Percona tools) do this better.
• Anyone expecting continuous replication or near-zero RPO — Velero is scheduled/snapshot-based, not a streaming replication solution.
• Shops wanting CNCF-graduated governance guarantees for compliance reasons — sandbox status may be a blocker in vendor risk assessments.
• Small clusters or single-tenant dev environments where kubectl manifests in git plus PV snapshots via your cloud provider are simpler and require zero extra infrastructure.
• Teams needing built-in multi-cloud object storage abstraction without configuring plugins — you'll need to manage BackupStorageLocation and VolumeSnapshotLocation plugins per provider (AWS, Azure, GCP, etc.), which adds operational surface area.

Alternatives

• Kasten K10 (Veeam) — commercial, more polished UI/UX and application-aware backup policies, but proprietary licensing cost.
• Portworx PX-Backup — tightly integrated with Portworx storage, strong for teams already on that stack.
• CloudCasa — SaaS-delivered backup for Kubernetes with a free tier, less infrastructure to self-manage than Velero.

Pricing

Velero itself is fully open source (Apache-2.0), free to use with no licensing cost. Commercial support is available through VMware Tanzu subscriptions if you need SLA-backed enterprise support; otherwise you're on community support (GitHub issues, Slack).