Nexus Repository Manager Guide

By Khimananda Oli | Last reviewed: August 2026

Managing binary artifacts across distributed teams requires a centralized source of truth, and this Nexus Repository Manager Guide provides the operational blueprint for deploying it correctly. Without a dedicated repository manager, build pipelines fail due to upstream outages, security vulnerabilities slip into production via unvetted dependencies, and storage costs spiral from duplicated binaries. I have deployed Sonatype Nexus OSS and Pro across dozens of environments, from air-gapped government data centers in Nepal to multi-region AWS architectures, and the difference between a fragile setup and a resilient one always comes down to initial configuration discipline.

How do you install and configure Nexus Repository Manager on Ubuntu?

Installation is straightforward, but most guides skip the production-critical steps like separating data directories and tuning the JVM. For a durable deployment, treat Nexus as a stateful service that requires careful resource planning. Before starting, ensure your server meets minimum requirements: 4 CPU cores, 8GB RAM (minimum), and fast SSD storage for the blob store. If you are managing infrastructure on Linux, reviewing Ubuntu server setup best practices ensures your base OS is hardened before installing application services.

System preparation and user creation

Never run Nexus as root. Create a dedicated system user and prepare the filesystem hierarchy to separate the application binary from persistent data. This separation simplifies upgrades and backup strategies significantly.

sudo apt update && sudo apt install -y openjdk-17-jre-headless wget
sudo adduser --system --no-create-home --shell /bin/false nexus
sudo mkdir -p /opt/nexus /opt/sonatype-work
sudo chown -R nexus:nexus /opt/nexus /opt/sonatype-work

Downloading and configuring the service

Download the latest Nexus Repository OSS tarball from the official Sonatype site. Extract it to /opt/nexus and create a symbolic link for version-independent paths. Configure the JVM heap size in /opt/nexus/bin/nexus.vmoptions; set -Xms and -Xmx to the same value (e.g., 4g) to prevent runtime resizing pauses. Point the data directory in /opt/nexus/etc/nexus-default.properties to /opt/sonatype-work.

# /etc/systemd/system/nexus.service
[Unit]
Description=Nexus Repository Manager
After=network.target

[Service]
Type=forking
LimitNOFILE=65536
ExecStart=/opt/nexus/bin/nexus start
ExecStop=/opt/nexus/bin/nexus stop
User=nexus
Restart=on-abort
TimeoutSec=600

[Install]
WantedBy=multi-user.target

Enable and start the service with systemctl enable --now nexus. The default admin password is stored in /opt/sonatype-work/admin.password; change it immediately upon first login.

What is the difference between proxy, hosted, and group repositories?

Understanding these three repository types is fundamental to using Nexus effectively. Misconfiguring them is the most common cause of build failures and storage bloat I see in audits.

• Proxy Repository: Acts as a cache for remote repositories like Maven Central, npmjs.org, or PyPI. When a client requests an artifact, Nexus checks its local cache first; if missing, it fetches from upstream, stores it, and serves it. This protects builds from upstream outages and reduces bandwidth.
• Hosted Repository: Stores your organization's internal artifacts. Use separate hosted repos for releases (immutable, versioned) and snapshots (mutable, development builds). Never mix third-party and internal artifacts in the same hosted repository.
• Group Repository: A virtual aggregation endpoint that combines multiple proxy and hosted repositories under a single URL. Clients configure only the group URL, and Nexus resolves artifacts from member repositories in priority order. This simplifies client configuration dramatically.

In practice, developers should never point directly at a proxy or hosted repository. Always expose group repositories to clients. This abstraction allows you to add new upstream sources or reorganize internal storage without breaking existing build configurations.

How do you integrate Nexus Repository Manager with CI/CD pipelines?

Integration requires configuring both authentication and repository endpoints in your build tools. For comprehensive pipeline patterns, see my guide on build automation best practices, which covers artifact promotion strategies that pair well with Nexus.

Maven settings.xml configuration

Configure Maven to use your Nexus group repository as a mirror for central. Store credentials in the encrypted settings.xml or inject them via CI environment variables—never commit plaintext passwords.

<settings>
  <mirrors>
    <mirror>
      <id>nexus-public</id>
      <mirrorOf>central</mirrorOf>
      <url>https://nexus.example.com/repository/maven-public/</url>
    </mirror>
  </mirrors>
  <servers>
    <server>
      <id>nexus-releases</id>
      <username>${env.NEXUS_USER}</username>
      <password>${env.NEXUS_PASS}</password>
    </server>
  </servers>
</settings>

Docker registry configuration

Nexus supports Docker registries with some networking considerations. Each Docker registry requires its own connector port or subdomain. Using subdomains (e.g., docker.nexus.example.com) is cleaner than port-based routing when behind a reverse proxy. Configure your CI runner to authenticate via docker login before push/pull operations, and use image tags that include commit SHAs for traceability rather than mutable latest tags.

NPM and other package managers

For npm, configure the registry in .npmrc pointing to your Nexus npm group. Use scoped packages (@yourorg/package) to clearly distinguish internal modules from public ones. Nexus supports NuGet, PyPI, Go modules, Helm charts, and raw file storage with similar patterns—each format has specific client configuration requirements documented in the Sonatype help system.

How do you secure Nexus Repository Manager for production compliance?

Security is non-negotiable for artifact repositories. A compromised Nexus instance can poison every build in your organization. From SOC 2 audits and ISO 27001 assessments, these controls consistently appear as findings when neglected.

Authentication and role-based access control

Disable anonymous access unless you have a specific public-facing requirement. Integrate with LDAP/SAML for centralized identity management. Create granular roles: developers get read access to groups and write access to snapshot repos; CI service accounts get deploy permissions to release repos; admins get full control. Never share the admin account.

Network and transport security

Always terminate TLS at a reverse proxy (Nginx or HAProxy) in front of Nexus. Restrict direct access to the Nexus application port (8081) to localhost only. Implement IP allowlisting for administrative interfaces. If operating in regulated environments, review Linux security hardening practices for the underlying host.

Vulnerability scanning and policy enforcement

Nexus Pro includes IQ Server integration for automated vulnerability scanning. For OSS users, integrate external scanners like Trivy or OWASP Dependency-Check in your CI pipeline before publishing. Implement cleanup policies to purge old snapshots and unused proxy cache entries—unbounded storage growth is a common operational failure. Enable audit logging and ship logs to your centralized observability stack; artifact repository access patterns are valuable forensic evidence during incident response.

Nexus OSS vs Pro: Which edition should you choose?

The decision depends on team size, compliance requirements, and tolerance for manual processes. Here is a practical comparison based on real deployments:

Choose OSS if you have fewer than 20 developers, no strict compliance mandates, and can tolerate single-point-of-failure risk. Choose Pro when you need automated security gating, high availability for business-critical pipelines, or vendor support for audit evidence. Many organizations start with OSS and upgrade when compliance audits demand it—plan your migration path early.

Implementing Nexus Repository Manager for Long-Term Reliability

A well-configured Nexus Repository Manager becomes invisible infrastructure—developers trust it, pipelines depend on it, and auditors accept it as evidence of supply chain control. Focus your initial effort on correct repository topology, disciplined access control, and automated cleanup policies rather than chasing advanced features prematurely. Monitor disk usage, JVM garbage collection pauses, and proxy fetch latency as your primary health indicators; these metrics predict problems before they cause build failures. When your artifact repository is stable, secure, and observable, everything downstream improves. If you need help designing or auditing your artifact management strategy, reach out to discuss your specific requirements.