This topic covers system requirements for the Nexus Repository.
Supported Nexus Repository versions
Sonatype's product development lifecycle is explained in Sonatype Sunsetting Information.
The supported versions are listed on the version status page.
Supported operating systems
Sonatype Nexus Repository supports the
Linux,Windows, andMacOSoperating systems. Sonatype has not tested nor supported other operating systems.Use a dedicated user account
We recommend using a dedicated operating system user account to run each unique process on a given host. The Nexus Repository process user must be able to create a valid shell.
Do not run Nexus Repository as the
rootuser.Required file handle limits
Nexus Repository consumes more file handles than the default value allowed by Linux or MacOS operating systems. Some container platforms (e.g., Amazon ECS) override the default limits set on the container. Running out of file descriptors leads to data loss. Increase the limit on the number of open file descriptors for the user running Nexus Repository.
See the topic, Adjusting the File Handle Limits for instructions on how to do this in your environment.
Supported web browsers
Our policy is to support the most recent modern browser version of your supported OS at the time of the Nexus Repository version release date.
No support for virus scanners
Sonatype does not officially support nor recommend using virus scanners with Nexus Repository. We have seen 10x longer startup times on Windows servers and significant performance impact when using a virus scanner to monitor the installation directory.
Sonatype Nexus Repository is tested on and supports OpenJDK.
As of release 3.71.0, Nexus Repository requires Java 17. Sonatype began providing a JVM with our Unix archive in release 3.78.0.
Nexus Repository is compatible with both Intel and AMD CPU architectures.
For historic Java support information, see our Java Compatibility Matrix.
For information on obtaining a suitable JRE, see Obtaining and Verifying Suitable JRE.
Performance is primarily bounded by IO (disk and network) rather than CPU. Available CPUs will impact longer-running operations and thread count. See the thread allocation algorithms of the web container.
See the Memory Recommendations by Profile Size section for CPU recommendation by deployment.
At a high level, expect to allocate up to two-thirds of available RAM to Nexus Repository; leaving one-third of RAM available for system processes and buffers.
Memory requirements vary by profile size. There is not a single defined requirement due to the complexity of all possible use cases. The section below outlines the memory and CPU recommendations for each node in small, medium, large, and very large profiles.
Highly available deployments must meet these requirements for all nodes in the cluster.
See our Nexus Repository Memory Overview topic for details about the different types of memory that Nexus Repository uses and examples of memory-related Java requirements.
Nexus Repository supports two database options: an embedded H2 database or an external PostgreSQL database.
New installations are configured to use an H2 database by default. Nexus Repository running with the embedded H2 database supports up to 20,000 requests per day or 100,000 components.
Workloads beyond these limitations are not supported. Container-based deployments are not supported in H2 deployments.
We recommend all deployments use an external PostgreSQL database. For best performance, the Nexus Repository should have a low-latency connection to the database. When using a cloud database, the Nexus Repository node must be in the same region.
Version 14+ of PostgreSQL is recommended.
Nexus Repository requires PostgreSQL version 11.9 or later, while high-availability deployments require PostgreSQL version 13 or later.
Nexus Repository does not support running PostgreSQL in an active/active cluster. The 2-node PostgreSQL cluster configuration specified in the profile sizing is an active writer and a read node, meant for quicker failover and backup purposes.
See configure PostgreSQL for new instances
See migrating to a PostgreSQL for existing instances
Nexus Repository is compatible with the following PostgreSQL providers:
Amazon RDS instance
Amazon Aurora PostgreSQL
Azure PostgreSQL Flexible Server
Google Cloud SQL for PostgreSQL
An instance of PostgreSQL that you provide
We do not support the pgpool or other tools to load balance requests to multiple PostgreSQL servers.
When deploying Nexus Repository and using PostgreSQL, we support the AWS, Azure, and GCP abilities to run PostgreSQL in multiple availability zones.
When deploying your own PostgreSQL servers, we recommend using Log Shipping or Streaming Replication to keep the non-primary server up to date.
We do not support reading from a stand-by server during normal operations.
After upgrading the PostgreSQL host operating system you may see exceptions with a specific message reporting duplicate key value violations.
Refer to the support article "PostgreSQL Index Corruption - duplicate key violation errors" for details on remediating the issue.
The Nexus Repository database user requires CREATE and USAGE permission on the specified schema.
The specified schema must also be on the search_path for that user.
Nexus Repository will then create and manage its tables, making it the owner of those objects; so, you do not need to specify any extra permissions.
Nexus Repository 3 instances using PostgreSQL databases must have the pg_trgm (trigram) module. This module may not be installed with PostgreSQL by default on all Linux distributions, which will result in an exception when attempting to upgrade.
See Installing the Trigram Module for installation instructions.
See Advanced Database Memory Tuning for examples of advanced database memory tuning based on different profile sizes.
Sonatype Nexus Repository's legacy embedded OrientDB database entered extended maintenance in August 2024.
Nexus Repository customers must migrate from OrientDB to a supported database.
Remain on the Nexus Repository 3.70.x version until you are able to migrate from OrientDB. Versions 3.71.0 and above do not support OrientDB.
Required disk space for Nexus Repository varies by deployment size and complexity. You must have at least 4GB available disk space at all times; if available disk space drops below 4GB, the database will switch to read-only mode.
Sonatype Nexus Repository requires disk space for two primary directories:
Application Directory - Size varies slightly per release; as of August 2024, it is around 390MB. It is normal to have multiple application directories installed on the same host over time as you upgrade.
Data Directory - Size varies based on complexity and formats. Plan for substantial disk space. Note that formats like Docker and Maven can use very large amounts of storage (500GB easily).
Nexus Repository has two primary storage requirements:
Embedded data: requires very responsive, fast storage, ideally local disk
Blob storage: requires moderately responsive, high-capacity storage
File System Optimization
You may use the following Nexus Repository 2 optimization suggestions for Nexus Repository 3 file system performance, however we recommend to use at your own discretion.
Consider the noatime option for your work directory mounts and limit the symbolic links as they increase the overhead when paths need to be resolved to an absolute file path.