VolSync moves volume bytes between Kubernetes clusters, and calls it alpha

A second copy of a volume, not a second copy of a cluster

VolSync exists to solve a narrow infrastructure problem: a Kubernetes persistent volume that lives in one cluster also has to live in another. The project describes itself as asynchronous data replication for Kubernetes volumes, and it is deliberately a mover of data rather than a reimplementation of storage. Two transports do the replication, rsync and rclone, and a third tool, restic, handles backups of the same volumes. The word asynchronous is doing real work in that sentence. Replication runs in the background, source and destination are not in lockstep, and a workload in the source cluster keeps serving while the copy is in progress, which is what distinguishes this from a storage system that would give you a synchronously mirrored volume. The audience is platform engineers running multi-cluster or multi-region Kubernetes who need a recoverable copy of a workload's data without asking the application to participate.

Six movers, and picking one is the main configuration decision

The repository layout shows how the design is organised, with a separate directory per mover: mover-rsync, mover-rsync-tls, mover-rclone, mover-restic, mover-syncthing and diskrsync-tcp. Each mover encapsulates one way of getting bytes from A to B, and the operator's custom resources are what select and configure them. The rsync pair splits plain rsync from a TLS variant, rclone is there for object storage targets, and restic is the backup path rather than the replication path. Syncthing is the outlier, and the project treats it as optional enough to be excluded at compile time, since the Makefile documents a build tag for it:

TAGS=disable_syncthing make test

The same tag can be used to exclude the mover from the manager binary. This build-tag arrangement is a small but revealing detail. It means the shipped image contains several independent tools, which keeps the operator general, and it also means a security review of a VolSync deployment is partly a review of the tools it embeds, not only of the operator code.

The kind cluster path, then a Helm install

The documented quick path runs against a kind cluster. The tooling comes first:

go install sigs.k8s.io/kind@latest
./hack/setup-kind-cluster.sh

The script starts a cluster and installs the CSI hostpath driver and the snapshot controller, which matters because those are the pieces a local cluster needs before volume copies can be exercised at all. The operator itself then goes in with Helm:

helm repo add backube https://backube.github.io/helm-charts/
helm install --create-namespace -n volsync-system volsync backube/volsync

After that the usage instructions on the documentation site cover setting up the replication relationships, and the examples/ directory in the repository has one directory per transport, including rsync/, rclone/, restic/ and syncthing/, plus application-shaped ones such as source-database/ and destination-database/. The presence of a kubectl-volsync directory in the tree also means there is a command line client in the project, separate from the operator binary.

The api/ directory is Apache 2.0, the controller is AGPL

The licensing is unusual enough to be worth reading closely, and the README sets out the exceptions explicitly. The project as a whole is licensed under the GNU AGPL 3.0 license, with the files within the api/* directories additionally licensed under the Apache License 2.0. The stated reason is to permit VolSync's CustomResource types to be used by a wider range of software, which in practice means a company can write a tool that talks to VolSync's custom resources without that tool becoming subject to AGPL. Documentation is under a separate licence, the Creative Commons Attribution-ShareAlike 4.0 International license. For a platform team this is the part to get right. If you only want to generate or consume the CRDs, the Apache grant covers you. If you modify the controller and run it as a service for other people, the AGPL obligations apply to that modified controller, and the repository carries the LICENSE file and a DCO.txt for contributions.

The maturity badge still says alpha

VolSync labels itself. The README carries a maturity badge whose message is alpha, alongside the read the docs badge, the Go report card and codecov badges, and workflow badges for documentation and the operator. That badge is the most honest summary of the project, and it should be weighed against the release history: v0.15.0 was published on 2026-03-05, a 0.16.0 release candidate on 2026-05-07, and v0.16.0 on 2026-06-10, with the last push on 2026-10-15. The project is under active development and has been for a while, but the version numbers are pre-1.0 and the maturity label has not changed. The codebase is large for a young project, with an api/ directory, internal/, cmd/, helm/, config/, bundle/ and an examples/ tree, and the go.mod requires Go 1.26.0 with Kubernetes libraries at v0.35.2, controller-runtime at v0.23.3 and the CSI external-snapshotter client at v8.4.0. That dependency set is a hint about what VolSync depends on in the cluster it manages.

Restic for backups, and the tooling around the operator

Backup is a separate mode from replication, and it uses restic. The Dockerfile shows this concretely, with a stage that copies the restic source and the minio-go helper into a workspace and builds restic with cgo enabled, alongside a stage that clones rclone at a pinned version and verifies the resulting git hash against the expected one before building it. That hash check is a supply-chain practice worth copying: the version tag and the commit it points at are both asserted, so a moved tag fails the build. The rest of the toolchain is a conventional Go operator setup. The Makefile pins controller-tools, golangci-lint, Helm, kubectl, kustomize, operator-sdk, pipenv and yq, and the repository carries a .golangci.yml, a pre-commit configuration, a renovate configuration, a SonarCloud properties file, a devcontainer, and custom-scorecard-tests and test-e2e directories. A .krew.yaml is present as well, which is the file format used for distributing a kubectl plugin.

Where VolSync is the wrong shape of answer

Three cases come up. The first is a stateful application that already replicates itself, a database with its own replication configuration, for which copying files underneath a running instance is at best redundant and at worst corrupting, and the source-database and destination-database examples in the repository show the project is aware of this pattern. The second is a requirement that is really about snapshots: if you need point-in-time copies that the storage system can produce, VolSync's restic mode is a heavier way to reach a similar outcome, and its dependency on the CSI snapshot infrastructure, visible in the kind setup script and in the external-snapshotter dependency, is not free. The third is an environment where the operator cannot be installed with the privileges it needs. The alternative approach worth comparing against is application level replication orchestrated by the operator, where the database chooses what to copy and the copy is consistent by construction. VolSync's approach is byte level and storage agnostic, which is its strength, and it is also the reason the maturity badge is still alpha, because moving bytes while an application writes them is the hard part.

Editorial conclusion

VolSync is the tool to reach for when a Kubernetes volume has to exist in two places at once, and specifically when snapshot based disaster recovery is not enough because the second site needs a live, mountable copy that applications can fail over onto. It is the wrong tool for stateful applications that have their own replication, since copying their files underneath a running database is a different problem, and it is a risky default for a platform team that cannot accept AGPL 3.0 in the controller. Before adopting it, confirm the maturity badge alpha is acceptable for your change process, read the api/ directory terms separately from the rest of the repository, and run the kind setup with the rsync example in examples/ before you trust it with a production volume.

Frequently asked questions

Official sources

1. backube/volsync on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases