OCIregistry

Spec sheet

Purpose

OCIregistry is a pull-only, pull-through caching OCI Distribution server that implements a subset of the OCI Distribution Specification.Read 11 Oct 2026 · aceeric.github.io

Deployment

The server can run as a single binary, a container, a Kubernetes workload using a Helm chart, or a systemd service.Read 11 Oct 2026 · github.com

License

The repository provides a modified MIT license that permits free use subject to its terms and disclaims warranties.Read 11 Oct 2026 · github.com

Administrative API

The administrative REST API supports pruning the cache, listing images, blobs and manifests, and stopping the server.Read 11 Oct 2026 · aceeric.github.io

Authentication and transport

Upstream access supports anonymous and basic authentication, HTTP and HTTPS, one-way TLS, and mutual TLS.Read 11 Oct 2026 · aceeric.github.io

AWS integration

External token authentication currently supports Amazon ECR through the AWS SDK and requires the host to have an AWS account context.Read 11 Oct 2026 · aceeric.github.io

Cache pruning

Pruning can target images by access time, creation time, or URL pattern, and supports a dry-run option.Read 4 Oct 2026 · aceeric.github.io

Cache storage

The image cache is persisted as files beneath one filesystem subdirectory, which can be copied to another location and served there.Read 11 Oct 2026 · github.com

External authentication

External token authentication is supported, and the documented token provider currently supports Amazon ECR.Read 4 Oct 2026 · aceeric.github.io

Image loading

Images can be preloaded from a text list of image URLs or imported from tarballs created by tools such as docker save or ctr images export.Read 11 Oct 2026 · aceeric.github.io

Kubernetes use

The project is intended as an edge OCI Distribution server for Kubernetes, including edge clusters, air-gapped clusters, and registry offload.Read 4 Oct 2026 · aceeric.github.io

Notable limit

Only one server instance can serve clients because the image store is served from an in-memory cache synchronized with mutexes.Read 11 Oct 2026 · aceeric.github.io

Observability

Prometheus metrics and a health endpoint are optional configuration settings, and the Helm chart enables the health endpoint by default for cluster workloads.Read 11 Oct 2026 · aceeric.github.io

Path limit

The maximum supported image path has four segments when the upstream namespace is included in the path; containerd namespace query parameters allow an additional segment.Read 11 Oct 2026 · aceeric.github.io

Registry client compatibility

The documentation demonstrates pulling through the server with Docker and also names Podman and Crane as supported client options.Read 4 Oct 2026 · aceeric.github.io

Security scope

The project documentation describes upstream authentication and TLS options, but the pages reviewed do not state security certifications or compliance attestations.Read 11 Oct 2026 · aceeric.github.io

Security-related transport

The project documents secure and insecure HTTPS modes, one-way TLS, and mutual TLS for upstream access.Read 4 Oct 2026 · aceeric.github.io

Single-instance limit

Because the server uses an in-memory cache synchronized with Go mutexes, the documentation says only one instance can serve clients and multiple Kubernetes replicas behind a service are unsupported.Read 4 Oct 2026 · aceeric.github.io

Target users

The project is designed mainly as a caching mirror for Kubernetes clusters, including edge, air-gapped, and development clusters.Read 11 Oct 2026 · aceeric.github.io

Upstream registries

One instance can pull from multiple internal, air-gapped, or public registries, including Docker Hub, Quay, registry.k8s.io, and GitHub Container Registry.Read 11 Oct 2026 · aceeric.github.io

Where Specifiction places it

• Container Registries#40 of 607.1