Introduction: The Changing Landscape of Container Registries

For years, Docker Hub has been the default destination for developers and enterprises storing container images. However, as cloud-native architectures evolve, relying solely on public infrastructure introduces challenges: unpredictable rate limits, rising subscription costs, data sovereignty concerns, and bandwidth bottlenecks. While established alternatives like Harbor or JFrog Artifactory exist, they often come with heavy resource footprints, complex database dependencies, and demanding operational overhead.

Enter Zot Registry. Zot (a production-ready, vendor-neutral OCI registry) is rapidly becoming the go-to solution for engineering teams looking to break free from Docker Hub. It is stateless, exceptionally fast, and designed from the ground up for the Open Container Initiative (OCI) specification. In this comprehensive guide, we will explore why Zot is a game-changer and how you can self-host it to achieve a highly optimized, unified repository for both your OCI images and Helm charts.

Why Choose Zot over Docker Hub and Harbor?

When engineering leaders look to transition away from Docker Hub, they usually gravitate toward Harbor. While Harbor is an excellent, feature-rich platform, its architecture requires multiple components, including PostgreSQL, Redis, and various microservices. For teams requiring a lean, highly efficient, and low-maintenance solution, Zot presents a compelling alternative.

True OCI Native Conformity: Zot does not just support OCI images; it is built strictly on the OCI image and distribution specifications. This means any artifact adhering to OCI standards—including container images, Helm charts, Cosign signatures, and WebAssembly (Wasm) modules—can be stored natively.
Zero External Dependencies: Unlike Harbor, Zot does not require an external database to index its artifacts. It can read directly from the underlying storage filesystem or object storage, massively simplifying backup, restoration, and disaster recovery.
Unmatched Resource Efficiency: Written in Go, Zot compiles into a single, lightweight binary. It consumes a fraction of the CPU and RAM required by traditional registries, making it ideal for everything from massive enterprise clusters to resource-constrained edge deployments.

Architecture Tip: Because Zot is stateless and lightweight, scaling it horizontally is as simple as launching multiple instances behind a load balancer pointing to the same shared object storage (such as AWS S3 or MinIO).

Core Capabilities: Unified Storage for Images and Helm Charts

Modern Kubernetes deployments rely on a combination of container images and Helm charts. Managing these across disparate platforms—such as storing images in Docker Hub and charts in a separate ChartMuseum instance—increases configuration drift and operational complexity.

Zot elegantly unifies these workflows. Since Helm v3 structurally supports storing charts as OCI artifacts, Zot acts as a singular, highly optimized source of truth. Security scanning, access control policies, and replication rules apply uniformly across your containers and your deployment manifests, streamlining your CI/CD pipelines.

Step-by-Step Guide: Deploying and Configuring Zot

Let us walk through configuring a production-ready, self-hosted Zot Registry instance. In this scenario, we will configure Zot to handle local filesystem storage, secure token-based authentication, and basic access control.

Step 1: Preparing the Configuration File

Zot is configured via a single JSON or YAML file. Create a file named config.json on your host system with the following layout:

{
  "distRepoVersion": "1.1.0",
  "http": {
    "address": "0.0.0.0",
    "port": "5000",
    "realm": "Zot Registry",
    "auth": {
      "htpasswd": {
        "path": "/etc/zot/htpasswd"
      }
    }
  },
  "storage": {
    "rootDirectory": "/var/lib/zot"
  },
  "log": {
    "level": "info"
  }
}

Step 2: Generating Authentication Credentials

To secure your registry against unauthorized image pulling and pushing, generate an htpasswd file containing the encrypted credentials of your authorized users:

Install the utility tools: sudo apt-get install apache2-utils (on Ubuntu/Debian).
Create the file and add your admin user: htpasswd -B -c ./htpasswd admin.
Enter and confirm a secure password when prompted.

Step 3: Launching Zot via Docker Compose

Using Docker Compose is the most straightforward method to manage your self-hosted Zot instance. Create a docker-compose.yml file in the same directory:

version: '3.8'
services:
  zot:
    image: ghcr.io/project-zot/zot-linux-amd64:latest
    container_name: zot-registry
    ports:
      - "5000:5000"
    volumes:
      - ./config.json:/etc/zot/config.json:ro
      - ./htpasswd:/etc/zot/htpasswd:ro
      - zot-data:/var/lib/zot
    restart: always

volumes:
  zot-data:

Run docker compose up -d to initialize your new registry. Zot will instantly begin listening on port 5000.

Integrating Zot into Your CI/CD and Helm Workflows

With your self-hosted registry operational, integrating it into your existing engineering pipelines is simple and frictionless.

Pushing Container Images

First, authenticate your local Docker or Podman daemon against your new registry:

docker login localhost:5000 -u admin

Tag an existing image and push it to your Zot repository:

docker tag my-app:latest localhost:5000/production/my-app:1.0.0
docker push localhost:5000/production/my-app:1.0.0

Managing Helm Charts via OCI

To push Helm charts directly to Zot, leverage Helm's native OCI capabilities. Package your chart locally and log into the registry using the Helm CLI:

helm registry login localhost:5000 -u admin

Push the packaged chart directly into your designated Zot repository:

helm push my-chart-0.1.0.tgz oci://localhost:5000/charts

Your chart is now stored under the exact same OCI specification as your application images, maximizing cross-compatibility and reducing administrative overhead.

Advanced Enterprise Features

Despite its minimal footprint, Zot is fully equipped for enterprise-grade workloads. When scaling up your infrastructure, consider unlocking these advanced configurations:

On-the-Fly Image Deduplication: Zot automatically deduplicates storage layers across repositories. If multiple application images share the same base layers, Zot stores only one physical copy, drastically lowering your storage costs.
Trivy Security Vulnerability Scanning: Zot can integrate directly with Trivy. This allows it to scan images automatically upon ingestion and expose vulnerability reports via the built-in UI or extensions API.
Distributed Multi-Tenant Access Control: Zot supports fine-grained access control policies (read, write, delete) mapped to specific repository paths, ensuring complete multi-tenant isolation within your organization.

Conclusion: Future-Proofing Your Cloud-Native Infrastructure

Moving away from Docker Hub does not mean you have to embrace the infrastructure complexity and heavy resource demands of legacy registries. Self-hosting Zot Registry offers an ultra-optimized, high-performance solution that handles both container images and Helm charts smoothly.

By shifting to an OCI-native repository, your organization eliminates third-party rate limits, reduces bandwidth costs via localized storage, and simplifies your overall devops architecture. If you are looking to build a lean, reliable, and modern cloud-native stack, it is time to deploy Zot.

Beyond Docker Hub: High-Performance OCI Image and Helm Chart Storage with Self-Hosted Zot Registry