# Kanister: application-level data protection workflows for Kubernetes

> Kanister is a Kubernetes-native framework for defining, curating and running backup, restore and copy operations on applications, expressed as blueprints, actionsets and profiles rather than as shell scripts inside a pod. It suits platform teams who need to protect stateful workloads in a way that understands the application.

**kanisterio/kanister** — An extensible framework for application-level data management on Kubernetes, Kanister is a Cloud Native Computing Foundation sandbox project and was originally created by the Veeam Kasten team.

- Repository: https://github.com/kanisterio/kanister
- Website: https://kanister.io
- Stars: 890 · Forks: 186
- Language: Go
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/kanisterio-kanister

## What Kanister does that a snapshot does not

The stated position is that Kanister is a data protection workflow management tool, and that it provides a set of cohesive APIs for defining and curating data operations by abstracting away the tedious details around executing data operations on Kubernetes, with the claim that it is extensible and easy to install, operate and scale. The project description adds the framing that it is an extensible framework for application-level data management on Kubernetes, that it is a Cloud Native Computing Foundation sandbox project, and that it was originally created by the Veeam Kasten team. That origin explains the whole design. A storage-level backup of a database running in Kubernetes captures the files, which is not the same as a consistent copy of the data, because the application was writing while the copy was taken. An application-level backup knows how to freeze the application, take the copy, and put it back, and expressing that knowledge as a reusable artefact rather than as a one-off script is what Kanister provides. The keyword in the framework's own description is application-level, and that is the distinction from every other backup tool in the space.

## Blueprints, actionsets and profiles are the three nouns

The tutorial is described as a walk through defining, curating and running a first data protection workflow using Kanister blueprints, actionsets and profiles, and those three objects are the mental model for everything else. A blueprint is the reusable definition of what to do to an application, and the highlight list says a blueprint can be re-used across multiple workflows to protect different environment deployments, which is the property that makes the approach scale across a fleet. An actionset is a specific instance of that blueprint bound to a particular application and environment, and a profile carries the credentials and connection details so that a blueprint can stay free of secrets and be reused. The separate blueprints repository holds many sample blueprints, and the list of what is covered is the best evidence of the scope: AWS RDS, Cassandra, Couchbase, Elasticsearch, etcd, FoundationDB, K8ssandra, MongoDB, MySQL, PostgreSQL and Redis, with several of them additionally having an OpenShift variant using DeploymentConfig. So a team running a fairly ordinary stack will find a starting point, and a team running something unusual will write their own blueprint against the function library.

## The data operation functions are the actual API

The framework gives you a collection of easy-to-use data operation functions that you add to a blueprint to express detailed backup and restore steps, and the examples named are pre-backup scaling down of replicas and working with all mounted volumes in a pod. The design goal stated in the highlights is that these functions are extensible and atomic, which is the property that makes a blueprint safe to re-run. A step either completes or the whole operation fails, which is what you need when a backup is half done and the application is in a strange state. The functions link out to their own documentation page, so the catalogue is the reference a blueprint author works from, and the set of them is much larger than the two examples, covering the filesystem and database operations a real backup needs. The value of a shared function library rather than per-operator shell scripts shows up in the third highlight about re-usable workflow artifacts, because a function that has been fixed once is fixed for every blueprint that uses it, rather than for the one operator who wrote it.

## Kubernetes is the substrate, and the CRDs are the API

The first highlight is that Kanister is Kubernetes centric, with the APIs implemented as Custom Resource Definitions that conform to Kubernetes' declarative management, security and distribution models. That is a deliberate choice about where the logic lives. Rather than a separate control plane with its own API and its own state, the workflows are objects in the cluster, so they are versioned with GitOps, admitted through the same admission controls as everything else, and scheduled by the same mechanisms. The second highlight is that Kanister is secured via RBAC, preventing unauthorised access to your workflows through the Kubernetes role-based access control model, which is the practical answer to who may run a restore. The execution model offers both options, asynchronous or synchronous task execution, with a data operation scheduled to run asynchronously in dedicated job pods, or synchronously via the Kubernetes apimachinery ExecStream framework. The asynchronous path is the one you want for a long restore, since a job pod survives the client that started it, and the synchronous path is the one you want when the operator is watching. The observability highlight rounds it out, with logs, events and metrics exposed to Prometheus, Grafana and Loki.

## Storage agnostic, and that is a feature and a burden

The second highlight is that Kanister is storage agnostic, allowing you to efficiently and securely transfer backup data between your services and the object storage service of your choice, and the framing is that you use Kanister to back up, restore and copy your data using your storage's APIs, and Kanister won't get in the way. The upside is real: you keep control of where the backup data lives, and you are not tied to a backup vendor's object store. The burden is that you now own the storage configuration, the credentials for it, the lifecycle of the data in it, and the question of whether anyone can restore from it. The dependency list reflects the scale of that, with the Azure SDK for Go, the AWS SDK for Go, kopia, the Kubernetes CSI external snapshotter client, and stow, which is the storage abstraction library, plus a long list of replace directives pointing several of those at Kasten-maintained forks. Those replaces are worth a comment, because they tell you that the project is not building against the upstream of everything it depends on, and the OpenShift pins are annotated in the go.mod as being held to a release branch to match a particular Kubernetes version. If you are running a distribution other than vanilla Kubernetes, that is the sort of detail that decides whether the framework works in your cluster.

## Installing, building and the state of the releases

The quickstart is a pointer rather than a procedure, and it is the right shape for something this configurable. You follow the instructions in the installation documentation to install Kanister on your Kubernetes cluster, and then walk through the tutorial to define, curate and run a first data protection workflow. The repository layout shows what a project of this kind accumulates. There is a helm directory for the chart, a pkg directory for the libraries, a cmd directory, a design directory for design documents, a build directory, a docker directory, a docs directory, a scripts directory, and a Dockerfile.in template rather than a fixed Dockerfile, which is how the build is parameterised per platform. The Makefile builds a binary named controller, and the version string comes from git describe so that a build identifies itself, with the architecture set covering amd64, arm, arm64 and ppc64le, and the container registry defaulting to the kanisterio organisation. The build can run inside a containerised environment, and there is a documented variable for the virtual machine driver used to install OpenShift, with a default OpenShift version for the apps. The governance files are present, with GOVERNANCE.md, MAINTAINERS.md, CODE_REVIEW.md and a DCO. The releases are 0.119.0 from 2026-05-13, 0.118.0 from 2026-02-03 and 0.117.0 from 2025-12-09, with the last push on 2026-10-19, so the project is active and still below 1.0.

## Conclusion

Kanister is a good fit for a platform team running stateful workloads on Kubernetes where a volume snapshot is not enough, because the framework's selling point is that a backup knows how to quiesce and restore the application rather than just copy its files, and the blueprints cover a wide set of databases. It is the wrong choice if you only have stateless workloads, since there is nothing application-level to protect, and it is the wrong choice if you want a self-contained backup product, because Kanister orchestrates operations and delegates the actual copy to your storage. It is also the wrong choice if you need a stable release cadence, since the last release in the list is 0.119.0 from 2026-05-13 and the project is still versioned below 1.0. Before adopting it, read the architecture documentation and the data operation functions list, because the functions are what you will be writing, and pick your storage before your blueprint, since the storage is what Kanister deliberately abstracts away. The project is Apache-2.0 licensed, the last push was on 2026-10-19, and it is a Cloud Native Computing Foundation sandbox project originally created by the Veeam Kasten team.

## FAQ

### What is Kanister and what does it do on Kubernetes?

It is a data protection workflow management tool and an extensible framework for application-level data management on Kubernetes. It provides cohesive APIs for defining and curating data operations, abstracting away the tedious details of executing them, so you can back up, restore and copy application data using your own storage APIs.

### What are blueprints, actionsets and profiles in Kanister?

A blueprint is the reusable definition of a data operation and can be re-used across multiple workflows to protect different environment deployments, an actionset is a specific instance of a blueprint bound to an application and environment, and a profile carries the credentials and connection details. The tutorial walks through defining, curating and running a first workflow with them.

### Which databases have Kanister blueprints?

The separate blueprints repository includes AWS RDS, Cassandra, Couchbase, Elasticsearch, etcd, FoundationDB, K8ssandra, MongoDB, MySQL, PostgreSQL and Redis, with additional OpenShift variants using DeploymentConfig for MongoDB, MySQL and PostgreSQL.

### How does Kanister run a data operation?

Either asynchronously, by scheduling the operation to run in dedicated job pods, or synchronously through the Kubernetes apimachinery ExecStream framework. The APIs are implemented as Custom Resource Definitions, access is controlled through Kubernetes role-based access control, and logs, events and metrics are exposed to Prometheus, Grafana and Loki.

### Is Kanister still being released?

Yes, though the versions are still below 1.0. The releases are 0.119.0 from 2026-05-13, 0.118.0 from 2026-02-03 and 0.117.0 from 2025-12-09, with the last push on 2026-10-19. It is a Cloud Native Computing Foundation sandbox project originally created by the Veeam Kasten team and is licensed under Apache-2.0.

## Sources

- [kanisterio/kanister on GitHub](https://github.com/kanisterio/kanister)
- [License: Apache-2.0](https://github.com/kanisterio/kanister/blob/master/LICENSE)
- [Project website](https://kanister.io)
- [README](https://github.com/kanisterio/kanister/blob/master/README.md)
- [Releases](https://github.com/kanisterio/kanister/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kanisterio-kanister