# Infrastructure-based Best Practices

When designing your Nexus Repository infrastructure, use the [Resiliency and High Availability](https://help.sonatype.com/en/resiliency-and-high-availability.html "Resiliency") 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](https://help.sonatype.com/en/scaling-with-proxy-nodes.html "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](https://help.sonatype.com/en/directories.html "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](https://help.sonatype.com/en/download.html "Download") pages and read the [Release Notes](https://help.sonatype.com/en/release-notes.html "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](https://help.sonatype.com/en/configuring-the-runtime-environment.html "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