I Built a Private Software Registry, and Four Different Tools Now Publish to It

I will be honest about where this one started. I watched the videos for this module, and
at the end I was completely lost. Not "need to review" lost. "The words make sense one at
a time but the whole picture will not form" lost.

So I threw the videos out and rebuilt it from a single idea. Once that idea landed,
everything else fell into place. Here is the whole thing, the way it finally made sense to
me.

The one idea: a registry is a pantry for software

When developers build software, their code needs ingredients: libraries other people
wrote. Normally every build runs out to the public internet to fetch those ingredients
fresh, every single time. That is slow, and if the public site is down or rate-limits you,
your build breaks.

No real kitchen works that way. Kitchens have a pantry. Ingredients get stocked once and
kept on a shelf, and cooks grab what they need from there.

An artifact registry is a pantry for software. It stores copies of the ingredients your
builds use, and it stores your own finished artifacts too. Nexus is one popular brand of
this pantry. That is the whole concept. Everything else is detail.

Three kinds of shelf

A registry stores things three ways:

• Hosted: your own artifacts. The jam you made yourself.
• Proxy: cached copies of public libraries. Shop flour kept on your shelf, so you do not run to the shop every time, and you still have some when the shop is closed.
• Group: one address that serves from both, so a build only needs one URL.

The shelves in my registry. You can see the types right there: hosted, proxy, group.

Running it as a limited user

Before publishing anything, the most important security decision. Nexus runs on a Linux
machine, and every program runs as some user. That user decides what the program can touch.

You never run something like this as root, the all-powerful user. You make a limited user,
literally called nexus, that can only touch its own files. If the application is ever
broken into, the attacker is trapped in that small world instead of owning the whole
machine. It is the difference between giving a cleaner the key to one room versus the
master key to the building.

Proof it runs as nexus, not root. That first column is the entire security lesson.

The part where it fought me

Real infrastructure work is never the happy path. The lab specified an old version of
Nexus that wanted an ancient Java, but I had a modern one. Then the download links kept
returning 404, because the vendor had rotated the versions and even changed the filename
format since the lab was written.

I learned to stop trusting a hardcoded version number and go to the official download page
for the current link. The newer version shipped with its own Java bundled inside, which
made the whole conflict disappear. Frustrating in the moment, but this is the actual job:
read the error, adjust, keep going.

Publishing four kinds of artifact

Here is the part that surprised me most. I published four completely different artifact
types, and they all work the same way underneath.

Java, with Maven:

Pushing my Java JAR to the registry.

Node, with npm. Python, with a tool called twine, and for that one I built a Python
package from scratch, something I had never done: a wheel file, described by a
pyproject.toml, built and uploaded.

My first Python package, sealed into a wheel.

And Docker, an image pushed to the registry:

A Docker image, the fourth and final type.

Once I had done the first one, the other three were variations on a pattern I already
knew: point the tool at Nexus, give it a credential, run a publish command. Four different
ecosystems, one shape. That was the moment it stopped being four things to memorise and
became one idea.

Least privilege, and the errors that taught it

I published everything as admin at first, which is fine for setup and wrong for a real
build pipeline. A pipeline's credentials leak constantly; you never hand it the keys to
everything.

So I made a deploy user that can only push, no admin, no delete. And setting it up, I kept
hitting "403 Forbidden" errors. One for the jar, another for the metadata. Each one taught
me that access control is iterative: grant the minimum, test, find you are one privilege
short, grant exactly that, and no more. The errors were the lesson.

Logged in as the deploy user: the admin controls are simply gone. It can do its job, and
only its job.

Automating the inventory

Clicking through a UI is fine for a human. Real operations automate. So I wrote a small
bash script that asks the registry's API what it holds and prints an inventory.

One command, and the whole registry reports itself: every artifact, across all four
types.

That is the leap from using a tool to automating infrastructure, and it is the difference
between clicking buttons and doing the job.

What I actually learned

Before this, if you had asked me how teams share build artifacts, I would have said they upload them to a repository like Nexus or JFrog for distribution and versioning, and for
control over what stays in the repository. That was right. But building it taught me the part I had not appreciated: how much of a registry is about control and safety, not just storage. The limited user. Anonymous access off. A deploy user that can push but not administer. A record of who uploaded what.

A registry is not a shared folder. It is a controlled, auditable gate that everything passes through. And a topic that completely lost me at the start became something I can now build with my own hands and explain to someone else. That is the part I am proud of.