Originally published on 2014-09-24; fully revised and updated.

Sonatype Nexus Repository Manager provides a central system for storing and distributing build artifacts and dependencies. For DevOps teams, that means more predictable builds, better control of external components, and a standard publishing target for internal packages.
Why repository management matters in CI/CD
A repository manager sits between your build tools and public package repositories, while also serving as an internal artifact store. This pattern helps reduce failed builds caused by external outages and improves traceability of what your teams consume and publish.
- Creates a central point for binary dependencies and internal artifacts
- Improves build reliability through local caching of external components
- Enables collaboration by sharing internally built packages across teams
- Increases visibility into dependency usage patterns
- Supports governance by controlling which upstream repositories are used
How Nexus fits into a delivery workflow
In most setups, CI jobs resolve dependencies from Nexus first. If a dependency is not cached, Nexus fetches it from an approved upstream source, stores it locally, and serves it to current and future builds. Build outputs are then published back to Nexus for deployment stages.
flowchart LR
A[Developer commits code] --> B[CI pipeline starts]
B --> C[Resolve dependencies via Nexus group]
C --> D{Dependency cached}
D -- yes --> E[Build and test]
D -- no --> F[Nexus proxies approved remote]
F --> G[Cache dependency in Nexus]
G --> E
E --> H[Publish artifact to hosted repo]
H --> I[Deployment pulls artifact from Nexus]
Nexus repository types and when to use them
Nexus deployments commonly use three repository patterns together: hosted, proxy, and group.
| Repository type | What it does | Best for |
|---|---|---|
| Hosted | Stores artifacts your organization publishes | Internal libraries, release artifacts, snapshots |
| Proxy | Caches artifacts from an external repository | Reducing internet dependency and improving build speed |
| Group | Presents multiple hosted/proxy repos as one endpoint | Simpler client configuration for build tools |
Client configuration examples
Use a group repository URL for most build clients so teams only configure one endpoint. Replace nexus.example.com and repository names with your actual values.
Maven (settings.xml mirror)
<settings>
<mirrors>
<mirror>
<id>company-nexus</id>
<name>Company Nexus</name>
<url>https://nexus.example.com/repository/maven-public/</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>Code language: HTML, XML (xml)
Gradle (single repository endpoint)
repositories {
maven {
url = uri("https://nexus.example.com/repository/maven-public/")
}
}Code language: JavaScript (javascript)
npm (registry override)
npm config set registry https://nexus.example.com/repository/npm-group/
npm pingCode language: JavaScript (javascript)
Historical references from the original post
The original article linked to the following resources. They are retained here for attribution and historical context; verify current official documentation before implementation.
- Nexus OSS manual setup (third-party tutorial)
- Installing Nexus (legacy Sonatype book link)
- Sonatype Nexus (legacy domain link)
- Nexus book reference (legacy link)
- Repository Management with Nexus (Sonatype resource link)
The original embedded YouTube gallery was broken by API key restrictions. Direct troubleshooting video link: https://www.youtube.com/watch?v=ZCfrNvu6nMc
Common pitfalls
- Letting developers bypass Nexus and pull directly from public registries
- Using unclear repository naming, making promotion and retention hard to manage
- Mixing artifact lifecycle stages without clear hosted repository boundaries
- Skipping routine cleanup and retention policies, leading to avoidable storage growth
- Granting broad write access instead of least-privilege repository permissions
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals