Infrastructure-based Best Practices

When designing your Nexus Repository infrastructure, use the Resiliency and High Availability documentation for the high-level concepts used in typical deployments. Include consideration for the following:

• Ingress - load balancer and/or reverse proxy
• Application Server - system and local storage for running the application
• Database Server - system for running the external postgres database
• Component Storage - network or attached file or object storage

The following best practices detail important considerations for scaling and maintenance of the instance used as your system of record.

Resiliency and High Availability

Start or migrate Nexus Repository to the external PostgreSQL database for production environments

• Nexus Repository will be completely replacing the internal Orient database with PostgreSQL for production instances
• Many of the new features and scalable deployment models will only support Postgres
• The "embedded" databases (Orient or H2) occupy the same JVM and may starve the main Nexus process
• Databases greater than 10GB or critical systems of record should migrate to PostgreSQL

Review the System Requirements while planning for future growth

• There are 2 primary considerations for scaling your deployment: access and storage
• Avoid the minimum requirements for production. These are there for testing only
• Starving the server of resources will lead to database corruption and service loss

Use your access control model to estimate your system requirements

• Use the following questions to frame your expected usage:
  • How frequently will users and systems access the server?
  • How many peak requests per minute do you expect?
    • (Frequency of builds multiplied by the average number of components)
  • Do you require complex access controls?
  • Does each team have its own repos or namespace that only they have access to?
  • Do you have hundreds of teams that will need their own set of repositories?
• Increasing the complexity of access will require more CPU and RAM resources

Scale your deployment by adding resources or dividing the load to other instance

• Adding more CPU and RAM will improve access performance
• Using faster disks will improve write times for importing repositories
• Consider separating out your development pipeline from your deployment artifacts
  • for example; using a stand-alone hosted docker repository for high traffic
• Consider having a separate read-only instance for offloading download traffic (See Scaling with Proxy Nodes)

Server Maintenance

Audit your storage requirements regularly to track growth predictions

• Without aggressive cleanup, storage will quickly grow, especially for container repositories
• Use high-performance / fast storage for the sonatype-work directory
• The blob stores can be configured on a slower network or object storage
• Consider using a mix of storage types (file vs object) to balance cost savings with critical performance

Regularly backup your Nexus Repository database and components

• Get familiar with the Directories
• Create internal documentation on backup and failover action plans
• Testing your backup and recovery process at least once a year; quarterly is highly recommended

Stay up-to-date on upgrading Nexus Repository

• Find the latest version on the Download pages and read the Release Notes
• Plan to upgrade your deployment at least once a quarter
• The product team typically releases once a month or sooner for critical patch releases
• Avoid upgrading production immediately after a new release
• Test upgrades in a test environment before deploying to production
• Backup your database and installation before upgrading

Document your repository configuration and process for making changes

• Configuring the Runtime Environment to the deployed instance to maintain the stability, performance, and overall health of the application
• Document any changes to this configuration in an internal wiki

Configure Nexus Repository to run as a service on the production server

• Create a service user to start and run the application, avoid using the root user

Configure your server behind a reverse proxy or a load balancer

• Offload configuration and workload for SSL termination
• Easier to failover to another system
• Redirect when implementing a new architecture
• Improve server performance