Skip to main content

Sonatype Nexus Repository Reference Architectures

Our Sonatype Nexus Repository reference architectures serve to help customers design a Nexus Repository deployment where all instances have sufficient resources. We have designed each architecture against the anticipated total load for a given profile based on real data and customer experience.

Using the proper reference architecture is vital to ensuring your deployment’s stability and performance. Failure to properly provision resources can result in poor performance and, in some cases, data integrity issues or data loss resulting from inappropriately using an embedded database.

How to Use These Reference Architectures

Each reference architecture describes deployment strategies and system requirements for a single Nexus Repository deployment. Many organizations use multiple Nexus Repository deployments to serve different business units or provide scalability across regions. It’s common for different deployments to have different loads. For example, a primary Nexus Repository deployment might be a multi-node cluster that handles developer requests and all of the nightly builds for a large organization. Meanwhile, a second deployment serves as a read-only application cache for a production data center and experiences much less traffic overall.

Combining Deployment Patterns with Reference Architectures

In conjunction with these reference architectures, we also provide an extensive deployment pattern library; many deployments use a combination of patterns to accomplish business needs. Some patterns (e.g., the star pattern or federated repositories) explain how to connect deployments to meet larger organizational needs.

Regardless of deployment pattern, it is vital to ensure that each individual deployment is properly provisioned for the load that it experiences as defined in these architectures.

Available Architectures

Use the table below to identify which profile best matches your anticipated needs.

Select the link to the appropriate deployment architecture from the header row.

Links to Reference Architectures

Architecture 1

Architecture 2

Architecture 3

Architecture 4

Architecture 5

Max User Count






Max Requests per Day






Max Repository Count






Max Blob Storage






Compatible Editions

Pro or OSS






  • User Count - The number of licensed contributing developers who are part of the software development lifecycle. This is normally a mix of users who directly access Nexus Repository and users whose work is compiled.

  • Requests per Day - The number of HTTP requests handled by the Nexus Repository deployment.

  • Repository Count - The number of proxy, group, and hosted repositories defined in the Nexus Repository deployment.

  • Blob Storage - The total size of binary assets that the Nexus Repository deployment manages.

Sizing Your Deployment

Sizing Existing Deployments

Existing Sonatype Nexus Repository deployments on versions 3.61.0+ have easy access to usage statistics that can help you establish your current scale. See our usage metrics help documentation for details on where to find this information.

Sizing New Deployments

When sizing a new deployment, it is important to consider projected usage and not rely solely on your anticipated user count. Actual usage varies significantly between similarly sized teams.

Consider whether your development teams will use the following practices when projecting load:


Impacted Metrics

Using Nexus Repository as a single ingestion route for all third-party components (highly recommended)

Request Rates

Build-on-commit practices

Request Rates and Storage

Cascading builds

Request Rates and Storage

Container use


Externally distributing components/application binaries

Request Rates

Long-term retention policies for components/application binaries



As a best practice, ensure you implement well-defined cleanup policies as early as possible to ensure that the content you keep always has a clear owner. See our cleanup policies help documentation for details.