Introduction

A modern software project is rarely built from only the files written by its own team. Even a small web service may depend on a web framework, a logging library, a JSON parser, a database driver, a testing framework, a container image, and several internal libraries produced by other teams. Each of these pieces must be found, downloaded, verified enough to use, stored, updated, and sometimes published again for other projects.

This book is about Nexus Repository Manager, often called simply Nexus: a repository management system used to store, proxy, organize, and control access to software artifacts. Sonatype’s Nexus Repository documentation describes Nexus as a repository manager for multiple artifact formats and repository types, including hosted, proxy, and group repositories [Sonatype, n.d.]. In practical terms, Nexus becomes a controlled hub between developers, build tools, public package registries, continuous integration systems, and deployment environments.

Before we learn buttons, configuration files, and repository formats, we need the larger idea: Nexus is not just a place to “put files.” It is infrastructure for the software supply chain.

Software is assembled, not merely written

When beginners first learn programming, a program may look like one file:

print("Hello, world!")

That file is source code: text written by a human in a programming language. But real software usually passes through a process called a build. A build transforms source code and related files into something that can be tested, installed, executed, or deployed.

The output of a build is called a build artifact. An artifact is a produced item with a defined purpose in the development process. Examples include:

• a Java .jar file produced from Java source code,
• a JavaScript package published to an npm registry,
• a Python wheel file used by pip,
• a NuGet package used by .NET projects,
• a Docker or OCI container image,
• a compressed .zip release bundle,
• a generated documentation archive.

The word artifact is useful because it does not assume one programming language or one packaging system. A .jar, a .tgz, a .whl, a .nupkg, and a container image are different physical file formats, but they play a similar role: each is a packaged result that another tool or person can consume.

For example, suppose a team writes a Java library called payments-core. The team may compile it into:

payments-core-1.4.0.jar

Another team can then use that artifact as a dependency in a billing service. They do not need to copy the source code manually. Their build tool can request the correct artifact by name and version.

That is the beginning of repository management.

Dependencies need a reliable home

A dependency is software that your project requires in order to build, test, or run. If your Java application uses a logging library, that library is a dependency. If your frontend project imports a date-formatting package, that package is a dependency. If your container image starts from ubuntu:24.04, that base image is also a kind of dependency.

Some dependencies are direct dependencies: your project explicitly names them. Others are transitive dependencies: your dependencies need them, even if you did not request them directly.

For example, imagine this simple chain:

my-service
└── web-framework
    └── http-parser

Your project directly depends on web-framework. But web-framework depends on http-parser, so http-parser becomes part of your dependency graph. A dependency graph is the network of packages and versions connected by “depends on” relationships.

This graph can become large. The problem is not only “Can my build tool download the packages?” The deeper questions are:

• Where do packages come from?
• Which version did we use last week?
• Can a build still work if the public internet is slow or unavailable?
• Who is allowed to publish internal packages?
• Can developers accidentally download a malicious package with a similar name?
• Are release artifacts preserved after publication?
• Can we remove old snapshots without deleting important releases?

Nexus helps answer these questions by providing a managed location for artifact storage and dependency delivery.

A repository is more than a directory

A repository is a storage location organized according to rules understood by build tools and package managers. At the simplest level, it stores files. But a useful repository also stores or serves metadata.

Metadata is data about data. In repository management, metadata tells tools what artifacts exist, which versions are available, how packages relate to each other, and where specific files can be retrieved.

For example, Maven, a widely used build tool in the Java ecosystem, uses a Project Object Model file, commonly called a POM, to describe a project’s coordinates, dependencies, build configuration, and other project information [Apache Maven Project, n.d.]. Maven artifacts are commonly identified by coordinates such as:

groupId:    org.example
artifactId: payments-core
version:    1.4.0

These coordinates are not random labels. They are structured identifiers. They allow Maven and compatible repository managers to locate the correct artifact and associated metadata.

In npm, a package might be identified differently:

@company/design-system version 2.3.1

In Docker-style image distribution, a container image might be referenced as:

registry.example.edu/platform/api:1.4.0

The formats differ, but the pattern is similar: a client tool asks a repository for a named artifact at a particular version or tag.

Nexus understands this world of structured artifact delivery. It does not treat every ecosystem as identical, but it gives administrators a common operational model for managing them.

Nexus as the controlled middle layer

Without a repository manager, developers and CI/CD systems often download dependencies directly from public registries:

developer laptop ───────► public registry
CI server        ───────► public registry
production build ───────► public registry

This can work for a small experiment. But as a project grows, direct access creates several practical problems. The same dependency may be downloaded repeatedly. Builds may fail when an external service is unavailable. Internal packages need a private place to live. Access control becomes scattered. Security teams have less visibility into what is entering the organization.

With Nexus, the flow becomes more controlled:

developer laptop ──┐
CI server        ──┼──► Nexus ───► public registries
release process  ──┘        └──► internal hosted repositories

Nexus can act as a proxy repository, a hosted repository, or a group repository. These terms will be studied carefully in Chapter 2, but we can introduce them now.

A hosted repository stores artifacts directly in Nexus. For example, your team may publish payments-core-1.4.0.jar to an internal Maven hosted repository.

A proxy repository represents an external repository. For example, Nexus can proxy a public Maven or npm registry. When a client asks Nexus for a dependency, Nexus can fetch it from the remote registry and cache it locally according to repository rules.

A group repository presents several repositories through one URL. For example, a Maven group might combine:

internal-releases
internal-snapshots
maven-central-proxy

A developer configures one repository URL, while Nexus decides which underlying repository can satisfy the request.

This middle-layer design is the core idea of Nexus. It reduces direct dependency on public networks, centralizes policy, and gives teams one place to manage artifacts across languages and tools.

Security begins with knowing what flows through the system

Software supply chain security has become a central concern in modern software engineering. A software supply chain is the sequence of people, tools, code, dependencies, build systems, repositories, and deployment steps involved in producing and delivering software. NIST’s Secure Software Development Framework describes secure software development as a set of practices that include protecting software, producing well-secured software, responding to vulnerabilities, and verifying components used in software [NIST, 2022]. The OpenSSF SLSA framework similarly focuses on improving integrity across source, build, provenance, and distribution processes [OpenSSF, n.d.].

Nexus is not a complete security program by itself. It does not replace careful code review, vulnerability management, secure build systems, or incident response. But it is a powerful control point because artifacts and dependencies pass through it.

For example, consider a university software engineering lab. Students build Java, JavaScript, and Python projects. If every laptop downloads dependencies from the internet independently, the instructor has little visibility into what packages are used. If the lab uses Nexus as the configured repository endpoint, then dependency flow becomes more observable and manageable. The instructor can teach repository groups, private publishing, version pinning, and cleanup policies in a realistic environment.

Now consider a company. A CI/CD pipeline builds an internal service and publishes a container image. If that image is stored in a managed repository, deployment systems can retrieve a known version later. If credentials are scoped correctly, developers may publish to development repositories while only release automation can publish to production release repositories. That difference is not just administrative neatness; it is part of reducing accidental or unauthorized changes.

Reliability matters because builds are promises

A build is a promise that a particular set of inputs can produce a particular output. In practice, that promise is often weakened by uncontrolled dependencies.

Suppose a build script says:

use library X, latest version

This may work today and fail tomorrow because “latest” can change. Suppose a public registry is temporarily unavailable. A CI job may fail even though the source code is correct. Suppose a snapshot artifact is overwritten with different contents. A later build may appear to use the same version but actually consume different bytes.

Nexus helps, but it does not magically make builds reproducible. Reproducibility means that repeated builds, given the same declared inputs and environment, produce equivalent outputs. Achieving this requires disciplined versioning, lockfiles where the ecosystem supports them, immutable release practices, checksums, controlled repository groups, and careful build configuration. Later chapters will return to these ideas, especially Chapter 12 on dependency caching and build reproducibility.

For now, remember this principle:

A repository manager improves reliability when it is used as part of a disciplined build and release process.

Nexus gives you mechanisms. Good engineering practice gives those mechanisms meaning.

What this book will teach you

This book begins from the reason artifact repositories exist, then builds toward secure and operationally responsible Nexus usage.

You will first learn the conceptual vocabulary: repositories, components, assets, metadata, formats, coordinates, repository policies, hosted repositories, proxy repositories, and group repositories. These terms matter because unclear vocabulary leads to unclear systems. If a team cannot distinguish a package, an artifact file, a repository, and a repository group, it will struggle to design a reliable artifact platform.

You will then install and run Nexus locally. A local installation is useful because it turns abstract ideas into visible behavior. You will create repositories, inspect storage concepts, examine logs, configure clients, upload artifacts, and see how build tools communicate with Nexus.

After that, the book moves through common ecosystems:

• Maven and Java builds,
• Gradle and other JVM workflows,
• npm and JavaScript projects,
• Python, NuGet, Docker, and raw repositories.

The goal is not to memorize every menu option. The goal is to recognize the shared pattern beneath different ecosystems:

client tool ── requests package/version ──► repository manager
repository manager ── serves or fetches artifact ──► client tool
repository manager ── stores metadata, policy, and access rules

Once that pattern is clear, we can design repositories for real projects. We will examine naming conventions, release flows, environment separation, access boundaries, authentication, authorization, cleanup, monitoring, backup, recovery, automation, and production deployment concerns.

The final capstone brings these ideas together: you will design a complete Nexus-based artifact platform for a multi-language project.

A small running example

Throughout the book, imagine a project called CampusHub, a fictional university application with several parts:

CampusHub
├── backend-api        Java service
├── frontend-web       JavaScript application
├── analytics-worker   Python service
├── shared-models      internal Java library
└── deployment-images  container images

CampusHub needs public dependencies, such as web frameworks and testing libraries. It also produces internal artifacts, such as shared-models and container images. Developers need fast downloads. CI jobs need stable dependency resolution. Administrators need access control and cleanup. Security reviewers need a clearer view of what enters and leaves the build system.

Nexus can serve as the hub:

Maven/Gradle clients ──► Maven repositories in Nexus
npm clients          ──► npm repositories in Nexus
pip clients          ──► PyPI repositories in Nexus
Docker clients       ──► Docker repositories in Nexus
CI/CD pipelines      ──► publish tested artifacts

This example is intentionally ordinary. Most organizations do not need an exotic repository design on day one. They need clear repository boundaries, sensible permissions, repeatable builds, and enough operational discipline to avoid surprises.

How to think while learning Nexus

As you study, keep three questions in mind.

First, ask: What is the artifact?
For a Java project, it may be a .jar. For a frontend project, it may be an npm package. For deployment, it may be a container image. If you cannot name the artifact, you cannot manage it well.

Second, ask: Who should be allowed to publish or consume it?
A student in a classroom, a developer on a feature branch, a CI release job, and a production deployment system should not necessarily have the same permissions.

Third, ask: What should remain stable over time?
Release artifacts should often be treated differently from temporary snapshots. Cached public dependencies should be managed differently from internal packages. Old artifacts may need cleanup, but careless cleanup can break historical builds.

These questions turn Nexus from a product interface into an engineering tool.

The journey ahead

Nexus sits at an important junction: close enough to developers to affect everyday builds, close enough to operations to affect deployment reliability, and close enough to security to influence software supply chain risk. That position makes it valuable, but it also means poor configuration can create confusion. A repository manager should reduce uncertainty, not add another layer of mystery.

The chapters ahead will therefore move slowly and deliberately. We will define each concept before relying on it. We will connect repository theory to client configuration. We will treat security and operations as normal parts of artifact management, not as advanced topics reserved for the end.

By the end of the book, you should be able to look at a software project and answer practical questions:

• Which repositories do we need?
• Which artifacts are internal and which are external?
• How should developers and CI systems authenticate?
• Which dependencies should be proxied?
• How do we publish releases safely?
• How do we keep storage under control?
• How do we recover if something goes wrong?

That is the purpose of Nexus Repository Management: to make artifact delivery understandable, controlled, secure, and reliable.

References

Apache Maven Project. n.d. “POM Reference.” Apache Maven. Accessed August 30, 2026. https://maven.apache.org/pom.html

NIST. 2022. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218. https://doi.org/10.6028/NIST.SP.800-218

OpenSSF. n.d. “SLSA Specification.” Supply-chain Levels for Software Artifacts. Accessed August 30, 2026. https://slsa.dev/spec/

Sonatype. n.d. “Sonatype Nexus Repository Documentation.” Sonatype Help. Accessed August 30, 2026. https://help.sonatype.com/en/sonatype-nexus-repository.html