Nexus Repository

Context

Every piece of software ships on top of other software. A modern application is mostly things it did not write — frameworks, libraries, base images, build tools. Those things live in repositories. Nexus Repository is where a lot of the industry keeps them.

It is the system of record for binaries inside an enterprise. When a build runs, it pulls from Nexus. When a release goes out, it is published to Nexus. When an auditor asks where a vulnerable log4j version came from three years ago, Nexus is the answer.

That sounds mundane until it breaks. A repository manager going down does not just slow a team; it stops every build in the company. Releases freeze. Incident bridges open. The cost of a bad hour is measured in engineering days.

About 70% of the Fortune 100 run on it. Banks, carmakers, airlines, chip designers, governments. The people using it will never meet me, and most of them do not know the product by name. They just expect their mvn install to work.

What I work on

I lead the team responsible for the core of Nexus Repository. The work splits into a few areas.

Artifact resolution. The read path — the moment a developer's build asks for a component and we return bytes. It has to be fast, correct, and durable under pressure. Caching, conditional requests, routing to upstream proxies, resolving transitive metadata without hammering public registries. Getting this wrong gets noticed within minutes.

Repository formats. Maven, npm, PyPI, Docker, Helm, NuGet, Conan, Conda, Go modules, Hugging Face — each format has its own protocol, its own quirks, its own idea of what a "version" means. A lot of the work is staying honest to each ecosystem while keeping the internal model consistent.

Scale. Some customers have petabytes of artifacts and tens of thousands of concurrent clients. That forces hard choices about storage layout, blob store federation, garbage collection, and what "eventually consistent" means when a CI job is waiting on the other end of the pipe.

Security. Supply-chain attacks are not hypothetical anymore. Signing, verification, namespace confusion, proxy poisoning — the repository is an attractive target and a natural place to enforce policy. A lot of my recent work has been about making security defaults the easy defaults.

Performance. Old code, lots of it, earning its keep. The discipline is measurement first. Adding a profiler in anger is always easier than reading the flame graph someone sent you six months ago.

OCI 1.1, up close

A lot of my recent attention has been on OCI 1.1 compliance. For readers not in the container-spec weeds: OCI — the Open Container Initiative — is the standard the rest of the world borrowed from Docker and then hardened into something every registry has to speak. Nexus has been OCI 1.0 compliant for years. 1.1 is the interesting upgrade.

The headline additions are the subject field on manifests, the new artifact-manifest media type, and the referrers API — the endpoint a client uses to ask "what things refer back to this image?" That last one is what lets signatures, SBOMs, and attestations live next to the artifact they describe, rather than in a separate, out-of-band system. In practice, it is the quiet plumbing that makes modern supply-chain security work.

What I shipped, with the team, is the referrers endpoint across our storage backends, plus a migration path for tenants already sitting on tens of millions of v1.0 images. The tricky part was never the spec. The tricky part was the fallback. Clients that do not yet speak 1.1 have to keep working, and a 1.1 response has to be synthesised on the fly when the underlying storage does not yet have a fast answer for a given image. Correctness first, speed second, and a migration you do not have to think about.

A thing I'm proud of

Late 2023, a large customer called us about component resolution latency. Their monorepo had grown past what their Nexus cluster could comfortably serve. p99 on metadata reads had drifted from ~40ms to over a second. Their CI fleet was burning machine-hours waiting on us.

I ran the investigation. The surface story was database contention. The real story was that we had been serving a particular class of Maven metadata request through a code path that assumed a much smaller catalog. It worked fine at one scale and collapsed at another. Classic.

I wrote a short design doc — two pages — proposing a read-side cache keyed on the resolution signature, with invalidation tied to the existing publish hooks. The team pushed back on parts of it. They were right. The first draft would have cached too aggressively and served stale metadata on edge cases the customer actually hit. We narrowed the scope.

Implementation took about six weeks across three engineers. I wrote the cache layer. Another engineer did the invalidation. A third wrote the load tests, which is the work nobody volunteers for and the work that actually ships the feature.

p99 went from ~1.1s to ~90ms on the customer's workload. We rolled it out behind a feature flag to a handful of large accounts first, then broadly. No regressions, no rollback.

The thing I am proudest of is not the number. It is that the fix was smaller than the first proposal, and someone on the team made it smaller. That is what a team is for.

What I've learned

Leading at this scale teaches you that the interesting problems are almost never the ones the ticket describes. A latency spike is rarely a latency problem. A flaky test is rarely flaky. The bug report is where the investigation starts, not where it ends.

It has also taught me to be suspicious of my own cleverness. The tempting fix is the one that makes me look smart in review. The right fix is usually the one that makes the code look obvious a year from now, to someone who has never met me. I have written both. I prefer the second.

The piece that surprised me most is how much of senior work is about subtraction. Fewer features. Fewer abstractions. Fewer meetings. Fewer words in the design doc. Less code in the diff. The teams that ship best, in my experience, are the ones most willing to say "we are not going to do that right now" out loud, in writing, to people who want a yes.

And ownership is heavier than I thought it would be when I wanted it. The pager has my name on it. The customers are real. The consequences are real. That is also the part of the job I would not trade.