Nexus Repository Reference Architectures
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 the deployment pattern, it is vital to ensure that each 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.
These architectures were revised in January 2025 to incorporate results of regular performance testing based on improvements made to the product.
Max HTTP Requests per Hour | 20,000 | 100,000 | 1,000,000 | 2,000,000 |
|---|---|---|---|---|
Max HTTP Requests per Day | 200,000 | 1,000,000 | 10,000,000 | 20,000,000 |
Min Database Configuration Needed | H2 | PostgreSQL | PostgreSQL and HA | PostgreSQL and HA |
Compatible Editions | Community Edition or Pro | Community Edition or Pro | Pro | Pro |
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:
Practice | 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 | Storage |
Externally distributing components/application binaries | Request Rates |
Long-term retention policies for components/application binaries | Storage |
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.
.