Nexus & JFrog Artifactory

In one line

Nexus and JFrog Artifactory are the two most widely used self-hostable artifact repositories — both act as a proxy and permanent store for exactly the kind of binary dependencies Phase 0.3's build tools already know how to fetch.

0/4 · 0%

Key ideas

01
SONATYPE NEXUS and JFROG ARTIFACTORY are both genuinely mature, widely-deployed BINARY REPOSITORY MANAGERS — software specifically built to store, organize, and serve exactly the kind of artifacts a real organization produces and consumes: JARs, npm packages, Python packages, Docker images, and more, often all within the same single tool.
02
Both act as a REMOTE REPOSITORY PROXY as well as a private store — configuring Maven or npm to fetch dependencies THROUGH Nexus/Artifactory (rather than directly from Maven Central or the public npm registry) means every dependency is cached locally after its first download, genuinely speeding up every subsequent build across an entire organization and providing real resilience if the public registry itself ever has an outage.
03
This PROXY-and-cache behavior connects directly to Phase 1.3's CI caching topic — the exact same underlying goal (don't re-download something that hasn't changed) just implemented at the organizational-infrastructure level rather than per-individual-pipeline-run, and genuinely complementary: a CI-level cache still helps even faster than an organizational proxy, but the proxy provides a durable, shared fallback for anything a specific pipeline's own local cache doesn't have yet.
04
Both tools also host genuinely PRIVATE, internal artifacts — an organization's own internal libraries, shared across many internal projects, published to a private repository hosted on Nexus/Artifactory rather than a public one, keeping proprietary code appropriately access-controlled while still making it consumable by internal build tools exactly like any public dependency.
05
REPOSITORY TYPES within these tools typically distinguish RELEASES (immutable, permanent, genuinely production-quality artifacts, directly connecting to Topic 5.1's immutability principle) from SNAPSHOTS (Maven's own term for in-development, potentially-changing builds, genuinely allowed to be overwritten since they're explicitly NOT meant to represent a stable, final version) — knowing which repository type a given artifact belongs in is a real, practical decision every publish makes.
06
Both tools provide genuine ACCESS CONTROL over who can publish to (and who can merely read from) specific repositories — directly the same least-privilege principle Phase 2.2's GitHub Actions secrets and every other course in this collection has applied in its own context, now scoped to 'who can push a new, permanent, potentially production-bound artifact.'

Code & diagrams

ProxyAndPrivateReposdiagram

One tool, two genuinely different jobs: caching the public world, and hosting your own private artifacts.

Rendering diagram…

maven-settings-proxy.xmlmarkdown

Routing Maven's own dependency fetches through a private Nexus instance instead of directly to Maven Central.

<!-- ~/.m2/settings.xml -->
<settings>
  <mirrors>
    <mirror>
      <id>company-nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>https://nexus.example.com/repository/maven-public/</url>
    </mirror>
  </mirrors>
  <servers>
    <server>
      <id>company-nexus</id>
      <username>${env.NEXUS_USER}</username>
      <password>${env.NEXUS_PASSWORD}</password>
    </server>
  </servers>
</settings>

<!-- Every "mvn" command now fetches through Nexus automatically,
     caching public dependencies and serving private internal ones —
     no change needed to pom.xml or any individual build command -->

Explain it without notes

Why does routing dependency fetches through a private Nexus/Artifactory proxy, rather than fetching directly from Maven Central, genuinely benefit an organization beyond just speed?

Why do release repositories treat artifacts as immutable while snapshot repositories genuinely allow overwriting?

Practice

If you have access to a Nexus or Artifactory instance, look at its configured repositories and identify which are proxy/remote repositories versus genuinely private, internally-hosted ones.

For a hypothetical internal library your team maintains, decide whether publishing it as a SNAPSHOT or a RELEASE is appropriate at a given point in its development, and explain your reasoning.

Trade-offs

↔
Self-hosting Nexus or Artifactory gives an organization genuine full control over its artifact storage and access policies, but it's real, ongoing infrastructure to run, secure, back up, and keep available — many organizations reasonably choose managed, cloud-hosted equivalents (AWS CodeArtifact, GitHub Packages, GitLab's own Package Registry) specifically to avoid this operational burden, trading some configuration flexibility for someone else managing the actual infrastructure.

Done when you can

I understand what a binary repository manager like Nexus or Artifactory actually does.
I can explain why proxying dependency fetches through one benefits speed and resilience.
I understand the difference between a release repository (immutable) and a snapshot repository (mutable).