# Ozone is an S3-compatible object store that ships its own docker-compose clusters

> Apache Ozone is a strongly consistent, fully replicated distributed object store for Hadoop and cloud-native environments, speaking both the S3 and HDFS APIs. The README's shortest path to a running cluster is a docker compose file fetched with curl and started with three data nodes, with a replication factor of one by default.

**apache/ozone** — Scalable, reliable, distributed storage system optimized for data analytics and object store workloads.

- Repository: https://github.com/apache/ozone
- Website: https://ozone.apache.org
- Stars: 1,332 · Forks: 654
- Language: Java
- License: Apache-2.0
- Published: 2026-10-17 · Updated: 2026-10-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/apache-ozone

## An object store that also speaks HDFS

Ozone is described as a scalable, redundant and distributed object store for Hadoop and cloud-native environments, optimized for data analytics and object store workloads. Beyond scaling to billions of objects of varying sizes, the README says it can function effectively in containerized environments such as Kubernetes and YARN.

The capability list is six lines, and each one is a claim you can hold the project to.

Multi-protocol support means S3 and Hadoop File System APIs, so an existing Hadoop workload and an S3 client can read the same data without a translation layer.

Scalability is stated as designed to scale to tens of billions of files and blocks and, in the future, even more. The hedge is honest.

Consistency is the claim that separates it from a filesystem with an S3 gateway: it is a strongly consistent object store, and the README attributes that to protocols like RAFT. Strong consistency means a write that has returned will be visible, which is what makes it usable as the backing store for analytics pipelines that read immediately after writing.

Cloud-native means it is designed to work well in containerized environments like YARN and Kubernetes, and the binary package is said to contain multiple sets of Kubernetes resource files showing deployment.

Security is the most detailed line. Ozone integrates with Kerberos infrastructure for authentication, supports native ACLs, integrates with Ranger for access control, and supports TDE and on-wire encryption. That is a real answer to the question that comes up with every object store, namely what a client authenticates against.

High availability is described as a fully replicated system designed to survive multiple failures.

## The compose cluster starts with no redundancy

The quick start is two commands, and the second one is where the surprise is.

```bash
curl -O https://raw.githubusercontent.com/apache/ozone-docker/refs/heads/latest/docker-compose.yaml
```

```bash
docker compose up -d --scale datanode=3
```

The compose file comes from a separate repository, `apache/ozone-docker`, on its `latest` branch rather than from a versioned release. That is convenient and it means the cluster you start is whatever that branch currently contains, so pinning it is on you.

The note that follows is the part to read: by default the cluster starts with replication factor set to 1, and it can be changed by setting the environment variable `OZONE_REPLICATION_FACTOR` to the desired value.

A replication factor of one means one copy of every block. So the three data nodes in the compose file are capacity and distribution, not redundancy, and the availability claim in the feature list does not apply to the quick start at all. For an evaluation that is fine and arguably deliberate, since it keeps the demo fast. For anything you keep data in, setting that variable is the first thing to do.

The rest of the quick start is an S3 walkthrough with the AWS command line tools, which is a good way to confirm the multi-protocol claim is real rather than aspirational.

## Any credentials work, because the cluster is not secured

The S3 walkthrough does something that would be alarming in any other context and is fine here.

You configure an access key and a secret key, and the README says that because the cluster is not secured you can use any arbitrary access key and secret key. The example exports `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` with values that look like a username and a hex string, and they are not real credentials.

Then you create a bucket and upload a file, pointing the tool at the local endpoint:

```bash
aws s3api --endpoint http://localhost:9878/ create-bucket --bucket=wordcount
ls -1 > /tmp/testfile
aws s3 --endpoint http://localhost:9878 cp --storage-class REDUCED_REDUNDANCY  /tmp/testfile  s3://wordcount/testfile
```

Port 9878 is the S3 endpoint of the local cluster. The upload sets a storage class of REDUCED_REDUNDANCY through the S3 API.

The file being uploaded is produced by `ls -1`, which makes this a smoke test rather than a tutorial. If the object appears in the bucket through the S3 API, the protocol stack works.

The security caveat is explicit in the README and worth restating once you leave localhost: an unsecured cluster accepts any credentials, so it must never be reachable from a network you do not control. The compose folder in the released artifact package contains a secure variant, which is the one to look at when you are evaluating the real deployment.

## Three ways to run it, from docker to Kubernetes

The README describes three deployment routes, and they differ in how realistic the cluster is.

The first is the compose file described above, which is the easiest way to start a cluster with docker.

The second is the released artifact. If you need a more realistic cluster you download the latest binary release package, untar it, and start a cluster with the help of docker-compose from inside the extracted tree:

```bash
cd compose/ozone
docker compose up -d --scale datanode=3
```

The detail that makes this route worth the extra step is what the compose folder contains: different sets of configured clusters, with the secure, HA and mapreduce example subfolders named explicitly. So the released package ships a secure cluster, a high-availability cluster and a MapReduce example, which is a better evaluation surface than one default configuration.

The third is Kubernetes, described as Ozone being a first class citizen of cloud-native environments, with the binary package containing multiple sets of Kubernetes resource files showing how it can be deployed.

Building from source is the fourth option and it is a Maven build like the rest of the Hadoop ecosystem:

```bash
mvn clean install -DskipTests
```

after which the same compose flow is available from the distribution output directory.

Note that `mvn clean install -DskipTests` skips the tests. That is the documented build for local development, and it means a source build gives you a cluster you have not verified.

## The module split and the two files about risk

The repository root explains the shape of the project more than the README does.

The repository contains the `hadoop-hdds/` and `hadoop-ozone/` source directories. The `dist/target/ozone-*/compose/ozone` path in the build instructions confirms that a distribution is produced from that structure.

There is also `dev-support/`, `tools/`, a `.devcontainer/` for editor environments, an `AGENTS.md` and a `CLAUDE.md`, and `.mvn/` for the Maven wrapper configuration with `pom.xml` at the root.

Two files at the root are worth more attention than their filenames suggest. `THREAT_MODEL.md` is a threat model committed to the repository, and `SECURITY.md` is referenced in the contact section as the place to report vulnerabilities. A storage system that integrates Kerberos, Ranger, TDE and on-wire encryption has an attack surface worth documenting, and having both files present indicates the project treats that as part of the deliverable rather than an afterthought.

The release history shows a maintenance branch alongside the current line: 2.2.0 on 2026-07-16, 2.2.1 on 2026-08-27, and 2.1.2 on 2026-09-18. A 2.1.2 published after 2.2.1 is a backport, which tells you the project supports more than one line and that the version you choose is a decision rather than a formality.

The licence is Apache-2.0, the project is a top level project under the Apache Software Foundation, and the last push was on 2026-10-15.

## Conclusion

Adopt Ozone if you need S3-compatible object storage with Hadoop integration and strong consistency. Skip it if your objects fit comfortably in one node's disk and you want no JVM in the path. Verify first the replication factor before you trust a compose cluster, since `OZONE_REPLICATION_FACTOR` defaults to 1 in the sample configuration and a factor of one is a single point of failure.

## FAQ

### How do I run Apache Ozone quickly?

Fetch the sample compose file with `curl -O https://raw.githubusercontent.com/apache/ozone-docker/refs/heads/latest/docker-compose.yaml`, then start the cluster with `docker compose up -d --scale datanode=3`. It defaults to a replication factor of one, which you change with the `OZONE_REPLICATION_FACTOR` environment variable.

### Which protocols does Apache Ozone support?

It supports both S3 and Hadoop File System APIs, and it is designed as a strongly consistent object store with consistency achieved through protocols like RAFT. You can exercise the S3 side with the AWS CLI against the local endpoint on port 9878.

### How is Ozone built from source?

With Apache Maven, using `mvn clean install -DskipTests`. Once built, the cluster is started from the distribution directory with `cd hadoop-ozone/dist/target/ozone-*/compose/ozone` followed by the docker compose command. Note that the documented build skips the tests.

## Sources

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

---

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