summ — a container registry with batteries included

Packaging software as Docker images is standard practice these days, and distributing those images, internally or to the public, means you almost certainly need a container registry. Docker Hub and the major cloud providers all offer managed registries, though the free tier, where there is one, tends to be very limited.

If you want to host your own, there are several open source registries available at the time of writing. Distribution and Harbor are the two most popular ones. Distribution is the reference implementation: it gives you push and pull, and nothing else. Harbor is a full-featured registry, including RBAC, vulnerability scanning, and a web UI; however, it requires separate PostgreSQL and Redis instances to operate, which significantly increases the complexity of installation and maintenance.

I’m introducing a new container registry — summ, a simple yet powerful registry with batteries included. The first release, 0.1.0, is out now.

Simple

summ is written in Rust, and compiled into a single binary executable, summ. Installing it and starting a registry takes two lines:

curl -fsSL https://summcr.com/install.sh | sh
./summ serve

If you’d rather not pipe a script into a shell, grab a binary from the releases page instead. Either way, that’s a complete registry on http://127.0.0.1:3110 — no database, no object store, nothing else to stand up alongside it. There’s a multi-arch container image too, if you’d rather run it in a container:

docker run -d -p 3110:3110 -v summ-data:/var/lib/summ summcr/summ

summ creates a data directory to store all layer blobs and metadata. This makes backing up and relocating the data extremely easy: stop the server, move the directory, and point it at the new location when you restart. You can also run multiple instances of summ on the same server on different ports, each with its own data directory.

Simple doesn’t mean cutting corners on the spec. summ passes the OCI distribution-spec conformance suite with zero failures on every profile, including the OCI 1.1 referrers API — 1032 checks, nothing skipped.

Metadata is a first-class feature

At first glance, pushing and pulling images seem to be the main interactions you have with a registry. However, anyone who has operated one for a while knows this is hardly the whole story. You regularly need to ask the registry about its own metadata: which manifests are no longer referenced by any tag and can be purged, or what the latest tag pointed at on a given day.

To answer these questions, a registry has to model repositories, manifests and tags, and the relationships between them. summ keeps all of this in an embedded RocksDB, under a binary key schema designed for exactly these lookups: repository names are interned into 4-byte ids so a long name isn’t repeated in every key, digests are stored as byte arrays rather than hex strings, and edge keys that only need to exist carry no value at all. No question is ever answered by walking a directory. In a local benchmark I pushed 7.42 GiB of layers at ~1.0 GB/s and pulled them back at ~1.1 GB/s aggregate across four concurrent clients.

Batteries included

summ also ships with several features that make it useful straight out of the box. There’s a built-in web UI, which gives you an easy way to discover repositories, manifests and tag histories. Three simple authentication modes — open, public-pull and private — let you run it as either a public or a private registry. Pull counts are recorded in hourly buckets and shown as a nice heat map in the UI. And a background purger reclaims unreferenced layer bytes after a grace period, so the space taken by deleted images comes back on its own.

There’s a live demo if you’d like to click around before installing anything.

What’s next

summ is a versatile container registry: it can host your personal projects, act as an ephemeral registry for CI runs, or serve workloads that only pull from within your local network. It’s still at an early stage, with several exciting features on the roadmap, including multi-node replication and support for object storage (e.g. AWS S3). If you have feedback or suggestions, please visit the GitHub repo and collaborate there.