ZOT OCI Registry

Self-hosted container registries, honestly reviewed. No vendor pitch, just what happens when you actually deploy it.

TL;DR

• What it is: Apache-2.0 OCI-native container image registry — a CNCF Sandbox project that stores and distributes container images and arbitrary OCI artifacts, strictly following the OCI Distribution Specification [4][5].
• Who it’s for: DevOps engineers and infrastructure teams who are hitting Docker Hub rate limits, want to eliminate registry SaaS costs, or need a private registry on hardware ranging from a Raspberry Pi to a cloud cluster [1][2][4].
• Cost savings: Docker Hub Pro runs $9/mo per user, Azure Container Registry starts at $5/mo (Basic) with storage charges on top, AWS ECR charges $0.10/GB/month plus data transfer. Zot self-hosted runs on a $5–10/mo VPS with no per-pull or per-GB pricing from the software itself [1][4].
• Key strength: Truly a single statically-compiled binary with zero runtime dependencies — no Postgres, no Redis, no sidecar process. Runs unprivileged on Linux, macOS, ARM, x86, bare-metal, or in Docker [4].
• Key weakness: Project contributor concentration — two contributors account for more than 51% of commits, and two organizations account for the same share of organizational contribution [5]. Not a tool for non-technical users; requires comfort with YAML configuration and Linux servers.

---

What is ZOT OCI Registry

Zot is an OCI-native container image and artifact registry. The project’s own description says it clearly: images stored in OCI image format, OCI Distribution Specification on-the-wire, that’s it. There are no proprietary extensions, no vendor-specific APIs, no lock-in to a particular cloud’s storage model.

It is a CNCF Sandbox project with around 1,961 GitHub stars and 186 forks. The Apache-2.0 license means you can run it internally, embed it in a product, or redistribute it without a commercial agreement [4][5].

What makes Zot unusual is what it isn’t. Most self-hosted registries are either a single-purpose Docker daemon add-on (the upstream distribution project that powers Docker Hub’s backend) or a full enterprise platform (Harbor, Quay) requiring a stack of dependencies — Postgres, Redis, Clair, a reverse proxy. Zot is neither. A single binary, no external dependencies, and it handles security scanning, auth, garbage collection, and a web UI from that one binary [4].

The scope of what it can store has expanded significantly from “just containers.” Because it natively implements the OCI artifact spec, you can push Helm charts, WASM modules, machine learning models, firmware images, arbitrary config files — anything ORAS (OCI Registry As Storage) can push [2]. One DEV Community post demonstrates pushing plain text files as OCI artifacts and pulling them back on an ARM device running Ubuntu [2]. This is genuinely useful for edge and IoT workflows where you want a unified distribution mechanism for software, config, and models.

---

Why people choose it

The choice to self-host a container registry almost always starts with one of three problems: Docker Hub rate limits, cloud registry costs, or privacy requirements.

Docker Hub rate limits are the most common trigger. Docker’s free tier caps unauthenticated pulls at 100 per 6 hours per IP — a number that CI systems in any real engineering team blow through in minutes. The Linode guide [1] describes deploying Zot specifically as a pull-through cache: images are pulled from Docker Hub once, cached locally, and subsequent pulls from your cluster hit Zot instead. Rate limit problem gone; also faster because you skip the round-trip to Docker Hub [1].

Cloud registry costs are the second trigger. AWS ECR, Azure ACR, and GCP Artifact Registry all charge for storage and egress. At moderate scale — say a 50-engineer team pushing frequent CI builds — those charges add up. A self-hosted registry on a VPS with large local storage is often cheaper past a certain pull-volume threshold.

The OCI artifact angle attracts a different user: people building edge infrastructure who want to treat their container registry as a universal artifact store [2]. The DEV Community post describes using Zot on a Raspberry Pi to distribute container images and arbitrary files to IoT edge nodes — both pushed and pulled with the same tooling [2].

The r/kubernetes discussion [3] captures the general decision landscape: teams choose between GitHub Container Registry (free but dependent on GitHub’s pricing decisions), cloud-specific registries (convenient but expensive at scale), and self-hosted options. Zot comes up as a production-credible option when teams want vendor independence. The observation that GitHub’s registry “is like a ticking time-bomb — free up to now, but could change” is why the self-hosted case exists at all [3].

---

Features

Based on the README, Linode guide, and awesome-docker-compose documentation:

Core registry:

• Full OCI Distribution Specification compliance — interoperable with any OCI-compliant tool (Docker, Podman, containerd, ORAS, Helm, etc.) [4]
• Stores container images, Helm charts, and arbitrary OCI artifacts [2][4]
• Runs as a single statically-compiled binary with no external dependencies [4]
• Works without root/elevated privileges [4]
• Supports Linux, macOS, Intel, ARM — from Raspberry Pi to cloud compute [2][4]
• Pull-through cache mode for proxying upstream registries like Docker Hub [1]

Authentication and authorization:

• OpenID Connect (OIDC) for SSO [1]
• htpasswd for simple username/password auth [1]
• API key support [1]
• Repository-level access control [1]

Security:

• Built-in image vulnerability scanning powered by Trivy [1][4]
• Integrated garbage collection and image deduplication [4]
• OpenSSF Scorecard and CII Best Practices badges on the repository [README]

Storage backends:

• Local filesystem (default)
• S3-compatible object storage backends for scale-out deployments [1][4]

Interfaces:

• REST API [merged profile]
• Web-based UI [1]
• CLI (zli) [1]

Scale-out:

• Designed for “scale-out production-ready” deployments [README]
• Supports high-availability configurations with shared S3-compatible storage [1][4]

What you do not get out of the box: multi-tenancy UI, GitHub/GitLab integration dashboards, or the kind of pipeline integrations that Harbor builds on top of its registry core. Zot is the registry primitive, not a platform.

---

Pricing: SaaS vs self-hosted math

Managed container registry pricing for comparison:

• Docker Hub Free: rate-limited pulls, 1 private repository
• Docker Hub Pro: ~$9/mo per user, unlimited private repos, 50,000 pulls/day
• Docker Hub Team: ~$15/user/mo
• AWS ECR: $0.10/GB/month storage + data transfer charges (free within same-region EC2)
• Azure Container Registry Basic: ~$5/mo + $0.10/GB/day storage
• GitHub Container Registry: free for public images; included in GitHub plans for private

Self-hosted Zot:

• Software license: $0 (Apache-2.0) [4]
• VPS to run it: $5–10/mo (4GB RAM Linode or equivalent is recommended in the Linode guide [1])
• Block storage or S3-compatible object storage if you need to scale past local disk

Concrete math for a Kubernetes team:

Say you have a 10-engineer team that builds and pulls container images aggressively. Docker Hub Team at $15/user/mo runs $150/mo. An Azure ACR Standard tier ($20/mo) plus 50GB of image storage ($7.50/mo) plus egress to your cluster adds up to $35–60/mo depending on pull volume. Zot on a Hetzner VPS with 200GB local storage: roughly $10/mo for the server, everything else is $0.

Over a year: managed cloud registry ≈ $420–1,800. Zot self-hosted ≈ $120.

The savings are real but the comparison is not quite apples-to-apples. Managed registries come with SLAs, managed TLS, integration with cloud IAM, and no operational burden. Zot requires someone to own the deployment, certificates, and upgrades. If your team doesn’t have that capacity, the SaaS premium might be worth it.

---

Deployment reality check

The Linode guide [1] assumes a Linux VPS with 4GB RAM, Ubuntu 24.04, and systemd. The deployment downloads the Zot binary (a single executable), creates a config file, and runs it as a systemd service. The guide also walks through TLS setup via Let’s Encrypt and htpasswd authentication.

What you actually need:

• A Linux server with 2–4GB RAM (4GB recommended if you enable Trivy scanning, which downloads approximately 1GB of vulnerability database artifacts on first start [1])
• A domain name pointing to your server if you want TLS
• TLS certificates (Let’s Encrypt works, Certbot --standalone mode is fine [1])
• htpasswd (from apache2-utils) for basic auth, or an OIDC provider for SSO
• No external database, no Redis, no additional services

Alternative deployment: Docker. The DEV Community ARM guide [2] does the entire setup in one command:

docker run --name=zot -p 5000:5000 -d ghcr.io/project-zot/zot-linux-arm64:latest

A Helm chart exists for Kubernetes deployments. A docker-compose example is documented at awesome-docker-compose.com [4].

What can go sideways:

• Trivy’s vulnerability database downloads ~1GB on startup. If you’re on a metered connection or a small instance, this is a surprise. The Linode guide explicitly warns about it [1].
• TLS is not optional in practice. Running a registry over plain HTTP means adding --insecure-registry or insecure_registries config entries in every client’s Docker or containerd config — workable for development, painful for a team.
• Pull-through cache configuration requires understanding Zot’s config file structure. The config is JSON/YAML with a non-trivial layout; misconfiguration silently breaks proxy behavior [1].
• The web UI is present but minimal. Don’t expect Harbor’s image management dashboard.

Realistic time estimate for a DevOps engineer: 30–60 minutes to a working instance with TLS and auth. For pull-through cache configuration: another 30 minutes following the Linode guide. For someone without Linux server experience: data not available — this tool is not aimed at that audience.

---

Pros and cons

Pros

• True single binary. No Postgres, no Redis, no sidecar containers. Download, configure, run. This is rare in the container registry space, where most self-hosted options require a multi-container stack [4].
• Runs anywhere. The same binary works on a Raspberry Pi, a cloud VPS, or a bare-metal Kubernetes node. The ARM-native image is a first-class artifact, not an afterthought [2][4].
• OCI artifact storage. Not just containers — Helm charts, ML models, config files, firmware. Anything ORAS can push, Zot can store [2].
• Pull-through cache. One deployment eliminates Docker Hub rate limits for an entire team or cluster with minimal configuration [1].
• Trivy integration built in. Image vulnerability scanning without running a separate service [1][4].
• Apache-2.0 license. No “Fair-code” restrictions, no commercial use limitations. Embed it in a product, redistribute it, use it internally — no legal call required [4].
• CNCF Sandbox project. Not a one-person side project; has institutional backing and a defined governance model [4][5].
• Unprivileged operation. Runs without root, which matters for security-conscious deployments [4].

Cons

• Contributor concentration. Two contributors account for 51%+ of all code commits; two organizations account for 51%+ of organizational contribution [5]. This is a project risk. If those two contributors or organizations step back, maintenance continuity is not guaranteed.
• Not for non-technical users. There is no guided setup wizard, no one-click installer, no managed cloud offering. This is a tool you configure with a JSON file and run as a Linux service [1].
• Minimal web UI. The UI exists and works for browsing images, but it doesn’t approach Harbor’s management dashboard or Docker Hub’s UX. Heavy UI users will be frustrated [4].
• 1,961 stars. Compared to Harbor (25K+ stars) or the upstream distribution project (8K+ stars), Zot has a smaller community, fewer tutorials, and less StackOverflow coverage. Debugging unusual configurations is harder [4].
• Trivy startup download. ~1GB downloaded on first start if scanning is enabled. Not a problem in most deployments, but an unexpected surprise on metered or slow connections [1].
• Config file complexity. Zot’s configuration is powerful but verbose. Pull-through cache, auth, TLS, and storage configuration are separate sections that require careful coordination [1].
• No hosted/managed option. No “Zot Cloud” if you want the software without the ops work. Your options are fully self-managed or a different product.

---

Who should use this / who shouldn’t

Use Zot if:

• You’re an engineering team that needs a private OCI registry and doesn’t want to pay AWS ECR or Azure ACR at scale.
• You’re hitting Docker Hub rate limits in CI and want a pull-through cache that’s free to run.
• You need to distribute OCI artifacts (Helm charts, WASM modules, ML models, firmware) to edge or IoT devices and want a unified registry primitive [2].
• You’re already comfortable with Linux server administration, TLS certificates, and YAML/JSON configuration.
• You need Apache-2.0 licensing — for example, embedding a registry into your own product or running it commercially without a separate license agreement.
• You’re running Kubernetes and want a registry that can scale with S3-compatible storage backends [1][4].

Skip it (use GitHub Container Registry) if:

• Your team is already on GitHub and your image volume fits within GitHub’s included storage. Free, zero ops, good enough for most small teams [3].

Skip it (use Harbor) if:

• You need a full enterprise platform: multi-tenancy, a capable management UI, replication policies, project quotas, and a mature web interface. Harbor is heavier and more complex to deploy, but the feature set is in a different category.

Skip it (use Docker Hub or managed cloud) if:

• You don’t have a Linux administrator on the team and nobody wants to own the infrastructure. Zot requires ongoing maintenance — certificate renewal, upgrades, monitoring. If that’s not someone’s job, pay for a managed registry.

Skip it entirely if:

• You’re a non-technical founder with no engineering support. This tool has no user-facing UI for managing your workflow — it’s infrastructure tooling for people who are already running Kubernetes or Docker in production.

---

Alternatives worth considering

• Harbor — The feature-complete enterprise OCI registry. Postgres + Redis + multiple services, but you get proper multi-tenancy, a real management UI, replication, and a large community (25K+ stars). The right choice if you need more than a storage primitive.
• Docker Registry (distribution) — The upstream project behind Docker Hub’s backend. Simpler than Zot in some ways, but without built-in auth, scanning, or UI. Zot is arguably a more complete replacement.
• GitHub Container Registry (ghcr.io) — Free for public images, included with GitHub plans for private. Zero ops, good enough for most teams that don’t need self-hosted control. The Reddit thread [3] notes it’s a common choice despite the dependency risk if GitHub changes pricing.
• AWS ECR / Azure ACR / GCP Artifact Registry — Managed, with cloud IAM integration and SLAs. The right call if you’re already deep in a cloud vendor’s ecosystem and the egress costs are acceptable.
• Gitea / Forgejo Container Registry — If you’re self-hosting your Git platform with Gitea or Forgejo, their built-in container registry is a zero-extra-infrastructure option.
• Nexus Repository — Multi-format artifact storage: Maven, npm, PyPI, Docker, OCI, and more in one platform. Heavier and Java-based, but the right tool if you’re managing artifacts across multiple package ecosystems.
• Quay.io (self-hosted) — Red Hat’s registry, open-sourced as Project Quay. Enterprise-grade, but complex to deploy and primarily maintained by Red Hat.

For a team that only needs a private container registry with no OCI artifact requirements and no Docker Hub rate limit problem: GitHub Container Registry or AWS ECR are less work. For teams that need the registry to run offline, on ARM edge hardware, or as part of a vendor-neutral infrastructure strategy: Zot is the cleanest option in that space.

---

Bottom line

Zot is infrastructure tooling for people who are already running containerized workloads and need to own their own registry. The single-binary deployment model is genuinely unusual and solves the main complaint about self-hosted registries — that they require running five services to get one feature. The pull-through cache capability alone makes it worth considering for any team burning through Docker Hub rate limits. The OCI artifact angle makes it interesting for edge and IoT use cases that most registry tools don’t address seriously.

The limitations are real: a smaller contributor base than Harbor or the upstream distribution project, a minimal web UI, and no path to managed hosting if you don’t want to run it yourself. The 2-contributor concentration flagged by Linux Foundation Insights [5] is worth watching for teams making a long-term infrastructure bet.

For non-technical founders looking to escape SaaS costs: this is not that tool. Zot saves engineering teams from cloud registry bills, not product teams from Zapier or Notion bills. If the problem you’re solving is container registry costs and your team has DevOps capacity, the math is straightforward — $10/month on a VPS beats any managed registry at meaningful pull volume. If you don’t have that capacity, Harbor is more mature but heavier, and managed cloud registries are the honest recommendation despite the cost.

If you want a hand deploying Zot or wiring it into your existing Kubernetes cluster, upready.dev handles that kind of infrastructure setup as a one-time engagement.

---

Sources

1. Vishwas Rajashekar, Linode Docs — “Deploy Zot as a Pull Through OCI Cache for Docker Hub” (Updated February 11, 2026). https://www.linode.com/docs/guides/deploy-zot-pull-through-oci-cache-docker-hub/
2. Sergio Méndez, DEV Community — “Zot and ORAS to create & manage edge container registries”. https://dev.to/sergioarmgpl/zot-and-oras-to-create-manage-edge-container-registries-3kam
3. r/kubernetes thread — “Which OCI-Registry do you use, and why?” https://www.reddit.com/r/kubernetes/comments/1l4r27e/which_ociregistry_do_you_use_and_why/
4. Awesome Docker Compose — “Zot OCI Registry: A simple, secure, OCI-native container image registry.” https://awesome-docker-compose.com/zot-oci-registry
5. Linux Foundation Insights — “zot — Project Health Score and Contributor Analytics”. https://insights.linuxfoundation.org/project/zot

Primary sources:

• GitHub repository and README: https://github.com/project-zot/zot (1,961 stars, Apache-2.0 license, CNCF Sandbox)
• Official documentation: https://zotregistry.dev