Cloud Parts

Zenko CloudServer

Scality’s open-source Node.js S3 server: a light S3 endpoint for development and tests, and a front end that can store objects in other clouds.

What it is
Object storage
Type
Open source
Made by
Scality
License
Apache 2.0
Facts checked
5 October 2026
Website Source code

What it is

Zenko CloudServer is the S3 front end of Scality’s commercial storage, published as open source. It is a Node.js server that parses S3 requests, checks v2 and v4 signatures, ACLs and bucket policies, then hands metadata and data to pluggable backends. Run on its own, it keeps metadata in a local LevelDB database and object data as files on disk, or holds everything in memory, which makes it a quick, disposable S3 endpoint for tests and CI. With the multiple data backend, each bucket or object gets a location constraint that sends its bytes to AWS S3, Azure Blob Storage or Google Cloud Storage while CloudServer keeps the metadata, so one S3 endpoint can sit in front of several clouds.

In Scality’s products the same code is the S3 connector in front of the RING, with metadata in a separate Raft-based service (bucketd) or MongoDB and accounts in Scality’s Vault IAM service. Background work such as replication and lifecycle expiry is done by another Zenko service, Backbeat. The server you start with docker run is a single instance: it doesn’t spread objects over machines or keep extra copies, so durability is whatever the disk under its volumes provides.

Why teams pick it

  • Starts in seconds with docker run; the in-memory backend gives a throwaway S3 endpoint for tests and CI
  • The same S3 layer Scality ships with its RING storage, with broad API coverage: versioning, object lock, bucket policies, tagging, CORS and website hosting
  • Can keep object data in AWS S3, Azure Blob Storage or Google Cloud Storage behind one S3 endpoint, chosen per bucket or per object
  • Apache 2.0 and actively developed by Scality, with new releases several times a month

Watch out for

  • Standalone it is one process on one machine, with no replication or erasure coding: not a replacement for a MinIO cluster
  • Leans on Scality’s wider stack: standalone, accounts come from a JSON file or environment variables, and lifecycle expiry and replication need Backbeat
  • Its public face is stale: the zenko/cloudserver image on Docker Hub was last updated in January 2023 and the Zenko site still shows 2019 posts; current images are on GitHub’s registry, ghcr.io/scality/cloudserver, and the docs still use the old image
  • Only accepts requests addressed to host names it knows (localhost and 127.0.0.1 by default); add others with the ENDPOINT variable or in config.json

Alternatives

What all object storage have in common →
Amazon S3AWSAWS’s object storage, and the de facto API most object stores copy.Apache OpenDALOpen sourceA Rust library, with bindings for Python, Java, Node.js, Go and more, that gives one API (read, write, stat, list, delete) over 50-plus storage backends: S3 and other object stores, local and HDFS file systems, Google Drive and Dropbox, and key-value stores.Apache OzoneOpen sourceA Hadoop-born object store that serves the same buckets over S3 and as a Hadoop file system.Azure Blob StorageAzureAzure’s object storage, with three blob types and an optional real directory tree for analytics.Backblaze B2 Cloud StorageCommercialLow-cost object storage on Backblaze’s own hardware, with its own API and an S3-compatible one.CephOpen sourceA distributed storage cluster that serves S3 buckets, block devices and a file system from the same pool of disks.Cloudflare R2CommercialS3-compatible object storage from Cloudflare that charges nothing for data going out.GarageOpen sourceA lightweight S3 object store that keeps copies of your data in several sites linked by ordinary Internet connections.Google Cloud StorageGoogle CloudGoogle Cloud’s object storage, where even the archive class answers in milliseconds.MinIOArchivedOpen sourceA self-hosted object store that speaks the S3 API. The open-source edition is archived and its images are gone from Docker Hub; MinIO now sells AIStor.PGSTY SiloOpen sourceA community-maintained fork of the open-source MinIO server, with builds, images, security fixes and the full web console.RustFSOpen sourceA young Rust reimplementation of MinIO’s design: S3-compatible, erasure-coded, Apache 2.0, and generally available since September 2026.SeaweedFSOpen sourceA distributed blob store with an S3 gateway and a file system layer, built to store and serve billions of small files.TigrisCommercialGlobally distributed S3-compatible object storage that moves data to where it’s read, with no egress fees.Versity S3 GatewayOpen sourceA stateless S3 server that exposes an existing file system, or another object store, through the S3 API.Wasabi Hot Cloud StorageCommercialS3-compatible object storage sold at one flat price per TB, with no egress or request fees.

How it fits with other technologies

A throwaway S3 endpoint for tests · bash

# in-memory backend: everything is gone when the container stops
# (the image is built for amd64; Docker emulates it on Apple silicon)
docker run -d --name cloudserver -p 8000:8000 --platform linux/amd64 \
  -e S3BACKEND=mem \
  -e SCALITY_ACCESS_KEY_ID=devkey -e SCALITY_SECRET_ACCESS_KEY=devsecret123 \
  ghcr.io/scality/cloudserver:9.4.7

export AWS_ACCESS_KEY_ID=devkey AWS_SECRET_ACCESS_KEY=devsecret123 AWS_DEFAULT_REGION=us-east-1
aws s3 mb s3://test-fixtures --endpoint-url http://localhost:8000
aws s3 cp ./fixtures/ s3://test-fixtures/ --recursive --endpoint-url http://localhost:8000
aws s3api put-bucket-versioning --bucket test-fixtures \
  --versioning-configuration Status=Enabled --endpoint-url http://localhost:8000

# to keep data instead, swap S3BACKEND=mem for:
#   -e S3BACKEND=file -e REMOTE_MANAGEMENT_DISABLE=1 \
#   -v cs-data:/usr/src/app/localData -v cs-meta:/usr/src/app/localMetadata

Moving from MinIO#

CloudServer is a good stand-in for MinIO in one common job: the S3 container in a Compose file or CI pipeline that tests code against S3. Swap the image, set S3BACKEND=mem (or file with two volumes), pass your keys as SCALITY_ACCESS_KEY_ID and SCALITY_SECRET_ACCESS_KEY, and add the service name other containers use, for example -e ENDPOINT=s3, so requests to http://s3:8000 are accepted. Plain S3 calls work unchanged; anything that used MinIO’s own admin API through mc admin won’t.

It is not a replacement for a production MinIO cluster: the free server is a single node, and Scality’s distributed S3 storage is its commercial RING and ARTESCA products. To copy existing data anyway, define the MinIO endpoint and CloudServer as two S3 remotes in rclone, run rclone sync minio:bucket cloudserver:bucket --checksum, and compare both sides with rclone check. Users, policies and lifecycle rules don’t travel with the objects and need setting up again.

See it in a real stack

No architecture uses Zenko CloudServer yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2009–2026

Scality, founded in 2009 by Jérôme Lecat, Giorgio Regni and three others, released the first version of RING, its distributed object and file storage software, in 2010. In June 2016 it published the code behind RING’s S3 interface as open source under the Apache 2.0 licence, as Scality S3 Server, a Node.js server that runs in a Docker container, so developers could build S3 applications and run them on premises, on AWS or both without code changes.

A year and 600,000 Docker pulls later, in 2017, Scality renamed it CloudServer and made it the core of Zenko, an open-source “multi-cloud data controller”: one S3 API in front of storage on premises and in AWS S3, Azure Blob Storage and Google Cloud Storage. Zenko also offered Orbit, a hosted portal for managing data placement and replication. A commercially supported Zenko followed in 2018.

The community side has since gone quiet: the Zenko website’s newest posts are from 2019 and the Docker Hub image stopped updating in early 2023. The code has not. CloudServer remains part of Scality’s products and gets new releases on GitHub several times a month.

Why it’s built this way

Open-source the S3 layer of the commercial product
Developers get the same S3 behaviour on a laptop as on Scality’s RING, so applications built against the free server move to the paid one unchanged.
Pluggable metadata and data backends
One server can run in memory for tests, on a local disk, in front of the RING, or against public clouds, depending only on configuration.
Store objects in their raw form in each cloud
Many tools compress, split or wrap data before sending it to the cloud, so only that tool can read it back. Zenko writes plain objects, which any client of the target cloud can read.

Timeline

  1. 2009

    Scality founded

  2. 2010

    First version of Scality RING released

  3. 2016

    S3 front end open-sourced as Scality S3 Server (June)

  4. 2017

    Renamed CloudServer; becomes the core of Zenko

  5. 2018

    Commercially supported Zenko released

  6. 2026

    9.4 releases continue on GitHub

Sources18 · facts checked 5 October 2026

Improve this page on GitHub