Artifact Repositories

An Artifact Repository (or Repository Manager) is a server that stores and serves every binary your organization builds or depends on — .jar files, Docker images, npm packages, Helm charts, Python wheels.

Without one, CI pipelines pull dependencies directly from the public internet on every run (slow, fragile, and a supply-chain risk). With one, dependencies are cached internally, builds are reproducible, and you control exactly what enters your supply chain.

Core Functions of a Repository Manager

A repository manager acts as the central hub for software components:

• Stores Build Artifacts: Acts as a secure, backed-up storage location for the .jar files, Docker images, or npm packages your CI/CD pipeline builds.
• Proxies Remote Repositories: It sits between your developers and the public internet. If a developer needs a public npm package, the repo manager downloads it, caches it locally, and serves it to the developer.
• Increases Build Speed: Because remote dependencies are cached locally on the organization’s network, builds run significantly faster and consume less external bandwidth.
• Insulates from Outages: If a public registry (like Maven Central or npmjs.com) goes down, your organization’s builds will not fail because the repository manager holds cached copies of all required dependencies.
• Security Scanning: Enterprise repository managers scan artifacts and their dependencies for known vulnerabilities (CVEs). They can block builds from consuming a library with a critical security flaw before it ever reaches your codebase. Many also generate SBOMs (Software Bills of Materials) — machine-readable inventories of every component in a build — which are increasingly required for compliance (US Executive Order 14028, EU CRA).

Note

Sonatype Nexus and JFrog Artifactory are the two most popular enterprise repository managers. They support almost every package format: Maven, npm, Helm, Docker, APT, Go, RubyGems, and more.

---

Types of Repositories

Inside a repository manager like Nexus, you will securely manage three main types of repositories:

1. Proxy Repositories A repository linked directly to a remote, public repository (like Node’s npm registry). When a component is requested, the proxy checks its local cache. If missing, it fetches it from the remote source, caches it, and serves it to the user. Subsequent requests are served instantly from the cache.

2. Hosted Repositories A completely private repository hosted on your servers. This is where your organization stores its own proprietary, internal artifacts and libraries that should never be exposed to the public internet for security and intellectual property reasons.

3. Group Repositories A collection of multiple repositories (both proxy and hosted) combined under a single URL point. This drastically simplifies configuration for developers. Instead of configuring their build tools to look at 5 different URLs, they configure it to look at one Group URL. The repository manager handles searching through the grouped repositories to find the requested package.

---

Semantic Versioning (SemVer)

All artifacts in a repository are versioned. The standard for software versioning is Semantic Versioning (MAJOR.MINOR.PATCH):

1.4.2
│ │ └── PATCH: Backwards-compatible bug fixes
│ └──── MINOR: New backwards-compatible functionality added
└────── MAJOR: Incompatible API changes (breaking changes)

Change Type	Example	When to Increment
MAJOR	1.0.0 → 2.0.0	Breaking API change; consumers must update their code
MINOR	1.4.0 → 1.5.0	New feature added; fully backwards-compatible
PATCH	1.4.1 → 1.4.2	Bug fix; no new features or breaking changes

A version prefixed with 0. (e.g., 0.9.0) signals that the API is still considered unstable and may change at any time.

SNAPSHOT vs. RELEASE (Maven/Nexus)

In the Java/Maven ecosystem, there are two distinct states for an artifact version:

• SNAPSHOT (e.g., 1.5.0-SNAPSHOT): An artifact that is still in active development. It is mutable - the same version number can be overwritten with a newer build. Used in the CI pipeline during development. Nexus will always fetch the latest snapshot.
• RELEASE (e.g., 1.5.0): An immutable, production-ready artifact. Once a release is published, its contents must never change. You cannot publish the same release version twice. The release is permanent.

Tip

A standard development workflow: developers build and test 1.5.0-SNAPSHOT throughout the sprint. Once the sprint is complete and the code is verified, the SNAPSHOT is promoted to a RELEASE (1.5.0), which is then deployed to production.

---

Components vs. Assets

When discussing repository managers, it is important to distinguish between logical components and physical assets.

• Component: A logical resource (like a library or a framework). It is identified by its coordinates (e.g., Group:Name:Version).
• Asset: The actual physical archive file associated with the component.

A single component often contains multiple assets. For example, a Java component might consist of a .jar binary asset, a .pom XML metadata asset, and a -javadoc.jar documentation asset. In Docker terminology, the component is the image, but the assets are the individual Docker filesystem layers reused across multiple components.

Cleanup Policies

Because organizations run automated CI/CD pipelines multiple times per day, artifact repositories can grow massively in size very quickly. Repository managers utilize Cleanup Policies to automatically delete old artifacts (e.g., “Delete all snapshot builds older than 30 days” or “Delete artifacts not downloaded in 90 days”) to reclaim storage space.