Zenko is Scality's Apache-2.0 licensed open source multi-cloud data controller, aimed at teams that want to keep control of data spread across local storage and public clouds behind a single unified namespace, access API, and search layer.
What it is
Zenko is described in its own README as Scality's open source multi-cloud data controller. It provides a unified namespace, an access API, and search capabilities for data stored locally, using Docker volumes or Scality RING, or in public cloud storage services including Amazon S3, Microsoft Azure Blob storage, and Google Cloud Storage. The project is a member of the SODA foundation, is documented in full at zenko.readthedocs.io, and its repository contains the installation resources needed to deploy the complete Zenko stack onto the Kubernetes orchestration system. The stack itself is made up of several components that are configured to talk to each other: nginx, Zenko Cloudserver, the Zenko Backbeat async replication engine, MongoDB, and redis.
The concrete problem it addresses is fragmentation across storage backends. Data kept partly on local volumes or Scality RING and partly in two or three different public clouds normally means a different namespace, a different API, and a different set of tools for each location. Zenko places one namespace, one access API, and one search interface in front of those backends, so the same S3-style workflow reaches data wherever it lives rather than requiring each provider's native object storage interface to be handled separately. It lives in the cloud-native container ecosystem, distributed through Kubernetes deployment resources and topics that also cover Helm, Docker Swarm, Kafka, and Grafana, and it is associated with Artesca in its topic list.
Key capabilities
- A unified namespace, access API, and search capability spanning local storage on Docker volumes or Scality RING and public cloud services such as Amazon S3, Microsoft Azure Blob storage, and Google Cloud Storage.
- S3-compatible object storage service provided by the Zenko Cloudserver component.
- Asynchronous replication handled by the Zenko Backbeat async replication engine.
- Complete Kubernetes deployment resources through the Zenko Kubernetes Helm Chart found in the
./kubernetes directory.
- A high-availability production configuration, which asks for pre-existing volumes rather than provisioning storage itself.
- An integrated stack of nginx, Zenko Cloudserver, Backbeat, MongoDB, and redis, all pre-configured to communicate with one another.
- Documentation hosted on Read the Docs, plus an "Open in GitHub Codespaces" path for quick exploration.
Who uses it and how
- Production operators who need high availability: the Helm chart deployment supports HA and expects pre-existing volumes, so the persistent storage layer is supplied by the operator.
- Kubernetes-centric teams, including those following the companion guide for deploying a HA Kubernetes cluster via the
scality/metal-k8s resources.
- Hybrid-cloud teams that keep data on local infrastructure, including Scality RING, while also using Amazon S3, Azure Blob storage, or Google Cloud Storage.
- Developers and evaluators who want to bring the stack up quickly, either in GitHub Codespaces or through the Helm chart.
- Contributors, who are directed to the Contributing Guidelines in the
scality/Guidelines repository and to GitHub Discussions for questions and suggestions.
Getting started
The README's path is deployment of the full Zenko stack on Kubernetes using the Zenko Kubernetes Helm Chart in the ./kubernetes directory, with full documentation published at zenko.readthedocs.io and a Codespaces option for opening the repository directly.
How it compares
The facts provided name no directly comparable tool and no list of paid products that Zenko replaces, so it stands alone in this registry. Within the facts, the closest references are its own Scality lineage and the SODA foundation membership rather than any competing project.
When to use it — and when not to
A self-hoster takes on operating the whole stack, which means running MongoDB, redis, nginx, Zenko Cloudserver, and Backbeat, and supplying pre-existing persistent volumes on Kubernetes or Docker Swarm. Teams that do not run Kubernetes or Docker Swarm, or that want a fully managed service rather than components to operate, should look elsewhere. The README is deliberately brief and defers to external Read the Docs material, and the repository holds installation and deployment resources rather than the application code of the individual components, which live in separate repositories.
