Zenko puts one namespace in front of S3, Azure Blob, GCS and local storage

A controller in front of several storage backends at once

Zenko is Scality's open source multi-cloud data controller. The description of what it does is short enough to state in full: it provides a unified namespace, an access API and search capabilities for data that is stored locally or in public cloud storage services.

The problem it addresses is the one every team hits a year into running on more than one cloud. Once objects live in Amazon S3, in Microsoft Azure Blob storage and in Google Cloud Storage at the same time, the application code ends up with three SDKs, three credential sets, three sets of error handling and three places where a bucket policy can drift out of line. A controller puts one addressable layer in front of that.

The audience is infrastructure and platform teams rather than application developers. The data can sit on local storage using Docker volumes or Scality RING, or in the three public clouds named in the project documentation. The licence is Apache-2.0, the project is a member of the SODA foundation, and the full documentation is published on Read the Docs at zenko.readthedocs.io.

What Zenko is not is a new object store. It does not replace S3, and it does not define a new durable format. It is the layer that decides which backend a request belongs to and gives the caller one consistent way to ask for it.

The four moving parts of the Zenko stack

The project documentation lists what the deployed stack consists of, and the list is short enough to be useful.

nginx sits at the front as the HTTP entry point. Zenko Cloudserver, which lives in the scality/S3 repository, is the S3-compatible server that speaks to the backends. The Zenko Backbeat Async Replication Engine, from the scality/backbeat repository, handles replication between locations. MongoDB and redis complete the stack, and all of them are configured to talk to each other.

That composition tells you where the complexity sits. Two of the five components are stateful, so a production deployment is not a stateless set of pods. It also tells you that this repository is not where the interesting code is. The server implementation and the replication engine live in separate repositories under the same organisation, and Zenko's own tree is the installation layer that wires them together.

The repository topics reinforce that reading. Alongside aws-s3, azure-storage, google-cloud, hybrid-cloud, object-storage and mongodb, the list includes helm, kubernetes, docker-swarm, prometheus, grafana, kafka, zookeeper and redis, which is the vocabulary of a packaged container deployment with monitoring rather than of an application library.

This repository is deployment resources, not the data plane

The overview section is explicit about the scope of the repository: it includes installation resources to deploy the full Zenko stack on the Kubernetes orchestration system. Everything else in the tree follows from that.

There is a solution/ directory and a solution-base/ directory, which is where the Kubernetes objects for the deployment are expected to live. A monitoring/ directory sits next to them, matching the prometheus and grafana topics on the repository. docs/ holds the documentation sources, and .readthedocs.yml is what connects that directory to the published Read the Docs site.

There is a version.sh script at the root, which is the kind of file that exists to keep a version string in step with the release, and a .devcontainer/ directory so that a contributor can work inside a container that matches the target runtime. A .github/ directory holds the automation, and CLAUDE.md is present at the root for coding agents.

The tests/ directory is worth a note. The primary language recorded for this repository is Gherkin, which is the plain text format used for behaviour driven development specifications, and that tells you the test suite is written as readable feature files rather than as unit tests in code. For a deployment repository, that is a sensible way to describe expected behaviour of a running stack.

The project documentation does not give a single install command here, so there is nothing to copy. The path a new user is pointed at is the Kubernetes installation described in the full documentation, and the contributing guidelines are shared across the Scality organisation.

High availability assumes you already have the volumes

The production section of the project documentation is short, and both of its points are prerequisites rather than features.

High availability is included, which is the expected behaviour for a piece of infrastructure that fronts production storage. The other point is that the deployment asks for pre-existing volumes. Zenko does not create or manage the storage it runs on, and it is not a Kubernetes operator that provisions a cluster for you. The volumes have to exist before the stack is brought up.

For the cluster itself, the documentation points to a separate Scality repository for deploying a high availability Kubernetes cluster, on the metal-k8s project. So there is a natural division: metal-k8s is the substrate, and this repository is the workload that runs on it.

That division is also a fair warning about the operational surface. Adopting Zenko means adopting Kubernetes, whatever the backends turn out to be. For a team that already runs containers in production, that is a known cost. For a team that does not, the controller is the smaller half of a much larger decision.

Preview tags on a development branch, not a stable release

The release history here is unusual and worth reading carefully before you plan a deployment.

The three most recent releases are 2.16.0-preview.4 from 2026-10-17, 2.16.0-preview.3 from 2026-10-08 and 2.16.0-preview.2 from 2026-09-21. The default branch is development/2.16, which is the branch a minor release line is prepared on. The last push to that branch was on 2026-10-20, so the work is current.

What is missing from that list is a stable 2.16.0. The pattern suggests the 2.16 line is still being stabilised, and the preview tags are how the Scality team ships candidate builds for evaluation. Nothing in the repository documentation explains the promotion path from preview to final, so if you are pinning a version for production, expect to talk to the project rather than to read a policy.

The consequence for an adopter is concrete. A preview tag is a reasonable thing to test against, and a poor thing to build a release process on. If your process requires a numbered stable artefact, the version that ships in the Zenko Cloudserver and Backbeat repositories is where to look, because this repository is the deployment layer rather than the server itself.

Why not just use the cloud provider's own SDK

The alternative to a multi-cloud controller is the arrangement most teams start with: call the provider SDK directly, keep the credentials in the application, and accept that there is more than one. The difference in approach is not about features but about where the abstraction lives.

With a direct SDK, every object access is written against a specific vendor's API. A request for a key that exists in two buckets needs branching logic in the application, and a request that needs to span both is a two step operation the caller has to build. With Zenko in front, the namespace is one, the access API is one, and search runs across the backends as a single operation.

Within Scality's own family there are two narrower choices. Scality RING is the on-premises storage system named in the project documentation, and Backbeat is the asynchronous replication engine that can move data between locations. Using RING plus Backbeat directly gives you Scality's storage and replication without the multi-cloud namespace, and it is the right shape for a deployment that stays on your own hardware. Zenko adds the piece where a single API must span your own hardware and three public clouds at the same time.

The cost of the abstraction is the cost of the controller. You add a layer that must itself be available, and the failure modes of that layer become part of your system's failure modes.

Editorial conclusion

Zenko is the right choice for an organisation that stores data in more than one cloud and wants one API and one namespace in front of it, and the wrong choice for a single-bucket application, where a provider's own SDK is simpler and has fewer moving parts. Before adopting it, read the documentation at zenko.readthedocs.io for the Helm based installation on a Kubernetes cluster, and note that the release tags here are preview builds of the 2.16 line rather than a stable release.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. scality/Zenko on GitHub