Trow: a Kubernetes-native registry that caches images and can refuse them

A registry that runs inside the cluster it protects

Trow is described in one line as image management and caching for Kubernetes, and the aim is stated plainly: building a small registry to make image management in Kubernetes easy.

The deployment model is the interesting part. The Trow Registry runs inside the cluster with very little resources, and is simple to set up so it caches every image. That is a different proposition from running a registry alongside the cluster, and it changes the failure story. A registry outside the cluster is one more service to operate, to back up and to keep reachable from every node, while a registry inside it is another pod that shares the cluster's fate.

The three use cases follow from that. Spin up a lightweight registry within Kubernetes, cache every image in a cluster when using the proper containerd or cri-o configuration, and prevent unauthorized images from touching the cluster with the admission webhook.

The last one is the reason this is more than a cache. A pull-through cache saves bandwidth and speeds up pulls, but it does not stop a pod from referencing an image that nobody approved. The admission webhook does, and it operates at the point where the cluster decides whether to admit a workload, which is the only place where a policy about images can actually be enforced.

The project is written in Rust, licensed under Apache-2.0, with its homepage at trow.io. The last push was on 2026-10-01, and the repository is not archived.

The feature checklist marks two things as not built yet

The README keeps a checklist, and two of the five entries are unchecked, which tells you more about the project's shape than any marketing sentence would.

What is done: it conforms to the OCI Distribution Specification for registries, it controls images running inside the cluster via approve and deny lists, and it automagically proxies any registry.

What is not done: a distributed architecture for HA and scalability, marked as coming soon, and full auditing and authentication of image access, marked as planned.

Those two unchecked boxes are the whole adoption decision, and they are the two things people most often assume a registry has. There is no high availability, so a single Trow instance is a single point of failure for image pulls inside the cluster, and the word distributed in the project vocabulary is aspirational rather than descriptive. There is no complete audit trail of who pulled what, and authentication of image access is not finished, which is a separate concern from the approve and deny list. The deny list controls what runs, not who fetched it.

The README is also upfront about the maturity, with a note that Trow is currently beta and you can expect to find rough edges. That line appears right under the install section, which is where a reader deciding to deploy it will look.

One more thing the README does not do is claim a comparison, it links to one. The section titled Comparison to Other Registries points at docs/COMPARISON.md rather than making claims in place, which is the right way to handle a comparison and also means the comparison is not readable from the README alone.

Installing means a helm chart and a containerd or cri-o change

There is very little install instruction in the README, and the reason is that the interesting part of the install is not Trow's own configuration.

The install section says a helm chart is available in the charts directory of the repository. That is the whole procedure. There is no kubectl apply of a manifest, no manual TLS setup described, and no list of command line flags for the server binary.

The real work is on the node side. The caching use case is conditional: cache every image in a cluster when using the proper containerd or cri-o configuration. The word proper is doing real work there, because a node only routes pulls through a registry mirror if its container runtime is configured to do so, and that configuration lives outside Trow. The registry also has to be reachable in a way the runtime trusts, which for TLS means issuing or wiring a certificate the node accepts.

The user guide is where the operational detail starts. The README says work has started on a User Guide and that it currently explains how to persist images and how to list repositories and tags via curl. Those two topics are the first ones a platform engineer needs, and the fact that the guide is in progress also tells you how much of the interface is settled. The curl examples for listing repositories and tags are the API surface a script would use, and they are in the guide rather than in the README.

For a reader deciding whether to try it, the useful order is the README for the feature list and the beta warning, docs/ARCHITECTURE.md for the design, docs/COMPARISON.md for how it sits against other registries, and docs/USER_GUIDE.md for the parts that are documented so far.

The Cargo manifest shows an axum server with a database and a Kubernetes client

The dependency list is a good map of the design, and it says more than the architecture guide's summary would.

The web stack is axum 0.8.1 with the tracing feature, axum-server 0.8.0 built on tls-rustls, and axum-extra for typed headers, sitting on tower and tower-http with cors, normalize-path, trace and set-header enabled. So the registry API is an axum service, and the HTTP surface is deliberately explicit about CORS and path normalization, which are the two things a registry sitting behind a proxy needs to get right.

Storage is sqlx 0.8 with the runtime-tokio, migrate, sqlite and json features, and there is a migrations/ directory in the repository root. The database is SQLite, and the migrate feature means the schema is applied by the binary rather than by hand, and the .sqlx/ directory in the root is sqlx's offline query metadata, which is how a Rust project checks its queries at compile time without a live database.

Kubernetes integration is the kube crate at 3.0.1 with the admission feature, plus k8s-openapi 0.27.0 built against the v1_33 API version. The admission feature is the webhook. The oci-spec and oci-client crates at 0.9.0 and 0.16.0 handle the OCI side, and oci-client is configured with rustls-tls and default features off, so the registry talks to upstream registries over TLS without pulling in the default TLS stack.

Two more details stand out. jsonwebtoken 10.3 with the aws_lc_rs feature and rust-argon2 3.0 are both present, which is the token signing and password hashing pair for whatever authentication does exist, consistent with the checklist marking authentication as planned rather than complete. And aws-sdk-ecr 1.5.0 with aws-config and aws-types is there, so a private registry in the AWS ecosystem is a supported upstream rather than an afterthought.

The manifest version is 0.10.0 on edition 2024, and the newest published tag is v0.7.2. The working tree is therefore ahead of the release line.

The repository layout shows a project mid-migration, not a finished product

The root listing tells you about the state of the codebase, and a few entries are worth pausing on.

There is a CHANGELOG.md, and a release history of v0.7.2 from 2025-02-21, v0.7.0 from 2025-01-28 and v0.7.0-rc3 from 2025-01-21. The pre-1.0 version line with release candidates in it is itself a signal, and so is the fact that the manifest now says 0.10.0 while the last tag is v0.7.2, a gap of three minor versions with no tag in between. Either the release process stalled, or work has landed on main without a release, and in both cases a team deploying this should pin a commit or a chart version rather than assume the latest tag is current.

There is a run_oci_conformance_tests.sh at the root, which is the practical answer to the conformance claim. Saying the registry conforms to the OCI Distribution Specification is a strong statement, and the presence of a script to run the conformance suite is what makes it checkable, and worth running before trusting a claim about a specific endpoint.

Then there are the standard Rust project files. Cargo.toml and Cargo.lock, rustfmt.toml, a .pre-commit-config.yaml and a .typos.toml, the last of which is a spell checker with a deliberately misspelled name, and it is configured in a repository where a large part of the vocabulary is unfamiliar words from the OCI and Kubernetes specifications.

The directories are docker/ for the container image build, charts/ for the helm chart, migrations/ for the database schema, docs/ for the architecture guide, the user guide and the comparison, src/ for the code, and tests/ for the test suite. The GitHub workflow badge in the README points at pr-tests.yaml, so tests run per pull request, which is the mechanism that keeps a beta registry from regressing quietly.

Where Trow is the wrong tool

The limits are visible in the checklist and in what the project has not built yet.

The first is availability. A distributed architecture for HA and scalability is listed as coming soon, so a Trow deployment is a single instance. For a cluster where image pulls must keep working when a node is being drained, a node is being patched, or a control plane is being upgraded, a single registry with a cache is a single point of failure that the operator has to think about. The cache mitigates this for images already pulled, and the miss is the problem case, which is exactly the moment the cluster is busiest.

The second is the audit and authentication gap. The checklist marks full auditing and authentication of image access as planned. The approve and deny lists control what runs in the cluster, and they do that at admission time, so they answer the question of which images are permitted. They do not answer who pulled an image, when, or with what credentials, and a security review that asks for an image pull audit will not find one here.

The third is the beta status, and the README says it plainly. Rough edges in a registry show up as failed pulls, and a failed pull in a Kubernetes cluster is a failed deployment. The scope of the problem is bounded, because the cache means the registry is only needed on the first pull of an image, but it is not nothing.

The fourth is the audience. This is a registry for Kubernetes clusters, run inside the cluster, with an admission webhook and containerd or cri-o integration. A team that needs a general purpose registry for a CI pipeline, or for developers pushing images from a laptop, is using the wrong tool, because the approve and deny list and the in-cluster deployment are the entire design, and the alternatives that already exist in most clusters are a hosted registry or the upstream registry itself with a mirror in front of it.

The right way to evaluate it is to read the comparison document the README points at, install the helm chart on a test cluster, and turn on the conformance script, because a registry that is going to sit in the pull path of every pod is exactly the component where a specification gap turns into a broken deployment.

Editorial conclusion

Trow is worth adopting for a team that wants image pull-through caching without standing up a separate registry service outside the cluster, and for a team that needs to control which images may run, since the admission webhook and the approve and deny lists address a real problem. It is the wrong tool while high availability matters, because the distributed architecture is listed as coming soon, and it is the wrong tool if you need full audit logging of image access, which is listed as planned rather than implemented. Before deploying, read docs/ARCHITECTURE.md and docs/COMPARISON.md, install the helm chart from the charts directory, and confirm which build you are running, since the manifest version 0.10.0 is ahead of the v0.7.2 tag.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Trow-Registry/trow on GitHub