Sonatype Nexus Repository System Requirements

Supported Versions

Sonatype's Product Development Lifecycle is fully explained in Sonatype Sunsetting Information. You can find specific information about supported versions in Sonatype Nexus Repository 3 Versions Status.

Operating System

Supported Operating Systems

Windows
Linux (most commonly used)
MacOS

Sonaype neither tests nor supports other operating systems.

Dedicated Operating System User Account

We strongly recommend using a dedicated operating system user account to run each unique process on a given host.
The Sonatype Nexus Repository process user must be able to create a valid shell.
As a security precaution, do not run Sonatype Nexus Repository as the root user.

Adequate File Handle Limits

Sonatype Nexus Repository typically consumes more file handles than the per-user default value allowed by Linux or MacOS operating systems.

Running out of file descriptors will lead to data loss. Therefore, you must permanently increase the limit on the number of open file descriptors for the user running Sonatype Nexus Repository to 65,536 or more before starting Nexus Repository.

Linux

In Linux, you can usually set persistent limits for a specific user by editing the /etc/security/limits.conf file.

Add a line like the one below to this file where <userid> is the user ID you are using to run Sonatype Nexus Repository:

<userid> - nofile 65536

Restart Sonatype Nexus Repository for the change to take effect.

Ubuntu

Ubuntu ignores the /etc/security/limits.conf file for processes started by init.d.

If Nexus Repository is started using init.d there, edit /etc/pam.d/common-session and uncomment the following line by removing the hash # and space at the beginning of the line:

# session    required   pam_limits.so

For more information refer to your specific operating system documentation.

Restart Sonatype Nexus Repository for the change to take effect.

systemd Users

If you're using systemd to launch the server, do not use the steps above.

Instead, modify the configuration file to add a LimitNOFILE line:

[Unit]
Description=nexus service
After=network.target

[Service]
Type=forking
LimitNOFILE=65536
ExecStart=/opt/nexus/bin/nexus start
ExecStop=/opt/nexus/bin/nexus stop
User=nexus
Restart=on-abort

[Install]
WantedBy=multi-user.target

Restart Sonatype Nexus Repository for the change to take effect.

MacOS

The method to modify the file descriptor limits on MacOS has changed a few times over the years. Please note your OS version and follow the appropriate instructions.

For OS X Yosemite (10.10) and newer

Create the file: /Library/LaunchDaemons/limit.maxfiles.plist

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
    <dict>
      <key>Label</key>
        <string>limit.maxfiles</string>
      <key>ProgramArguments</key>
        <array>
          <string>launchctl</string>
          <string>limit</string>
          <string>maxfiles</string>
          <string>65536</string>
          <string>65536</string>
        </array>
      <key>RunAtLoad</key>
        <true/>
      <key>ServiceIPC</key>
        <false/>
    </dict>
  </plist>

If this file already exists, then ensure the value is at least 65536 as shown.

The file must be owned by root:wheel and have permissions -rw-r--r--.

sudo chmod 644 /Library/LaunchDaemons/limit.maxfiles.plist
sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist

Reboot the operating system to activate the change.

Add a new line to $install-dir/bin/nexus.vmoptions containing:
```
-XX:-MaxFDLimit
```
Restart Nexus Repository to activate the change.

For OS X Lion (10.7) up to OS X Mavericks (10.9)

Create and edit the system file /etc/launchd.conf using this command:
```
sudo sh -c 'echo "limit maxfiles 65536 65536" >> /etc/launchd.conf'
```
Reboot the operating system to activate the change.
Add a new line to $install-dir/bin/nexus.vmoptions containing:
```
-XX:-MaxFDLimit
```
Restart Nexus Repository to activate the change.

Windows

Windows operating systems do not need file handle limit adjustments.

Docker

The Nexus Repository Docker images are configured with adequate file limits. Some container platforms such as Amazon ECS will override the default limits. On these platforms it is recommended that the Docker image be run with the following flags:

--ulimit nofile=65536:65536

Java

Nexus Repository requires a Java 8 Runtime Environment (JRE).

Obtaining and Verifying Suitable JRE

The distributions for OSX and Windows include suitable runtime environments for the specific operating system. The distributions for Unix do not include the runtime environment. If you prefer to use an external runtime or use a Unix operating system, you can choose to install the full JDK or the JRE only. You can confirm the installed Java version with the java -version command, for example:

$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

When multiple JDK or JRE versions are installed, you need to ensure the correct version is configured by running the above command as the operating system user that is used to run the repository manager.

In the event you have a non-standard location you need to update the configuration to specify a specific JDK or JRE installation path. To set the path for a specific Java location open the bin/nexus script and locate the line INSTALL4J_JAVA_HOME_OVERRIDE. Remove the hash and specify the location of your JDK/JRE:

INSTALL4J_JAVA_HOME_OVERRIDE=/usr/lib/jvm/openjdk-8

The startup script verifies the runtime environment by checking for the existence of the nested bin/java command as well as major and minor version of the runtime to be the required 1.8. If the configured runtime is not suitable, it will proceed with a best effort to locate a suitable runtime configured on the path or via the JAVA_HOME environment variable. If successful, it will start up the repository manager with this JVM. This allows you to have a dedicated runtime environment for the repository manager installed that is not on the path and not used by other installed applications. Further, you can separate upgrades of the Java runtime used by the repository manager from upgrades of the runtime used by other applications.

CPU

Performance is primarily bounded by IO (disk and network) rather than CPU. Available CPUs will impact longer running operations and also the thread allocation algorithms of the web container.

Minimum CPUs: 4

Recommended CPUs: 8+

Memory

Configurable Memory Types

The following table describes the configurable memory types for Sonatype Nexus Repository deployments:

Memory Type	Description	Notable Requirements
JVM Heap Memory	Stores runtime application objects	You must specify a min (-Xms) and max (-Xmx); these values should be identical Do not increase the heap memory larger than recommendations or set the min and max to be different; this will cause performance issues Min allowable is 2703M If you go beyond 8G, ensure there is enough RAM to handle and that G1GC garbage collection is enabled
JVM Direct Memory	Direct buffer memory representing the OS's native memory used by JVM process Allocated outside of and distinctly from heap memory	Required only for OrientDB Min allowable is 2703M Must configure a max value (host physical/RAM * 2/3) - JVM max heap
Host Physical Memory	Total memory allocated to the entire OS or virtual hardware Commonly called RAM	Min allowable is 8G; no max limit Minimum unallocated host physical/RAM memory should be no less than 1/3 of total physical RAM to allow for virtual memory swap max heap + max direct memory <= host physical/RAM * 2/3

Visit the Configuring the Runtime Enviroment page to learn how to change the default memory settings.

Instance Memory Sizing Profiles

These profiles help gauge the typical memory requirements needed for a dedicated server host running Sonatype Nexus Repository.

Due to the inherent complexities of use cases, one size does not fit all and this should only be interpreted as a guideline.

Sonatype Nexus Repository Recommendations by Profile Size

Profile Size	Profile Description	CPUs	Disk Size (Blob)	RAM	Heap Memory
Small	< 20 repositories < 20GB total blob store size single repository format type	8	20GB	8GB	Min: 2703M Max: 2703M
Medium	< 50 repositories < 200GB total blob store size a few repository formats	16	200GB	16GB	Min: 4G Max: 4G
Large	< 200 repositories > 200GB total blob store size diverse repository formats	32+	200GB or more	32GB	Min: 8G Max: 8G
Very Large	200+ repositories ~10TB total blob store size diverse repository formats	32+	10TB or more	64GB	Min: 12G Max: 12G

Postgres Server Recommendations by Profile Size

Profile Size	Profile Description	CPUs	Disk Size	RAM
Small	< 20 repositories < 20GB total blob store size single repository format type	4	100GB	16GB
Medium	< 50 repositories < 200GB total blob store size a few repository formats	8	200GB	32GB
Large	< 200 repositories > 200GB total blob store size diverse repository formats	16	200GB or more	32GB or more
Very Large	200+ repositories ~10TB total blob store size diverse repository formats	16	300GB or more	64GB

Example Maximum Memory Configurations

-XX:MaxDirectMemorySize is for OrientDB only

Physical/RAM Memory	Example Maximum Memory Configuration
8GB	-Xms2703M -Xmx2703M -XX:MaxDirectMemorySize=2703M
12GB	-Xms4G -Xmx4G -XX:MaxDirectMemorySize=4014M
16GB	-Xms4G -Xmx4G -XX:MaxDirectMemorySize=6717M
32GB	-Xms8G -Xmx8G -XX:+UseG1GC -XX:MaxDirectMemorySize=15530M
64GB	-Xms12G -Xmx12G -XX:+UseG1GC -XX:MaxDirectMemorySize=35158M

Advanced Database Memory Tuning

To apply database tuning settings like those below, amend the postgresql.conf file, save, and restart the database.

If you are unsure where the conf file is located, you can use the following command:

psql -U postgres -c 'SHOW config_file'

Small

max_connections = 200
shared_buffers = 4GB
effective_cache_size = 12GB
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 10485kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
max_parallel_maintenance_workers = 2

Medium

max_connections = 300
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 10485kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

Large

max_connections = 400
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 10485kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 16
max_parallel_workers_per_gather = 4
max_parallel_workers = 16
max_parallel_maintenance_workers = 4

For OrientDB, see additional memory tuning procedures.

Database Requirements

We highly recommend that you have your Nexus Repository 3 instance use an external PostgreSQL database. See our documentation on configuring Nexus Repository Pro for an external PostgreSQL database or on migrating an existing Nexus Repository 3 instance to a PostgreSQL database.

PostgreSQL (Recommended) PRO

Compatible PostgreSQL Versions

Sonatype Nexus Repository requires PostgreSQL version 11.9 or newer.
High Availability deployments require PostgreSQL version 13 or later.

PostgreSQL 15+ no longer allows global write privileges to public. If using PostgreSQL 15+, you must explicitly grant permissions to users in order for them to have permission to create something inside of the public schema.

Compatible PostgreSQL Providers

Amazon RDS instance
Amazon Aurora PostgreSQL
Azure PostgreSQL Flexible Server
An instance of PostgreSQL that you provide

For best performance, Nexus Repository should have a low-latency connection to the database. If you are using a cloud database, then the Nexus Repository node should also be run in the cloud in the same region.

Required PostgreSQL Database User Permissions

The Nexus Repository database user requires CREATE and USAGE permission on the specified schema, which also needs to be on the search_path for that user. Nexus Repository will then create and manage its own tables, making it the owner of those objects; so, you do not need to specify any extra permissions.

Required Trigram Module for PostgreSQL Database

Nexus Repository 3 instances using PostgreSQL databases must have the pg_trgm (trigram) module, which we will eventually be leveraging for search performance improvements. This module may not be installed with PostgreSQL by default on all Linux distributions, which will result in an exception when attempting to upgrade. If you find yourself in this situation, you will need to install the postgresql-contrib package available from your Linux distribution. In order to install it, the PostgreSQL user must have CREATE privileges on the current database. This can be granted using a command like the following.

grant create on database <database_name> to <database_user>;

After granting CREATE privileges for your database, you will then need to install the postgresql-contrib package available from your Linux distribution. For example, you might use the following for Fedora:

sudo dnf install postgresql-contrib

Once installed, execute the following command to create the extension. If your JDBC URL does not specify a schema, then use public:

create extension pg_trgm schema <schema>;

Once that is done, you should see the extension listed:

select * from pg_extension;

See our knowledge base article for further information.

PostgreSQL Database Maintenance

The following tasks can help your PostgreSQL database achieve optimum performance over time. These should be done outside of normal working hours to reduce impact on active users as the tasks can impact performance while running.

H2

Container-based deployments are not supported.
H2 supported workload limitation is 20K requests per day and 100K components; workload beyond these limitations is not supported.

OrientDB

We strongly recommend against running Nexus Repository 3 on an embedded database within container orchestration environments such as Kubernetes. Doing so can lead to severe data corruption.

Ongoing performance analysis has shown that OrientDB is unsuitable for use beyond 20K requests per day and 100K components.

If you need to exceed these limits, migrate to a PostgreSQL database.

Temporary Directory

The temporary directory at $data-dir/tmp must not be mounted with noexec or repository manager startup will fail with java.lang.UnsatisfiedLinkError message of failed to map segment from shared object: Operation not permitted.

Disk Space

Application Directory

The size of this directory varies slightly each release. It currently around 330 MB. It is normal to have multiple application directories installed on the same host over time as repository manager is upgraded.

Data Directory

When available disk space drops below 4GB, the database will switch to read-only mode.

On first start, repository manager creates the base files needed to operate. The bulk of disk space will be held by your deployed and proxied artifacts, as well as any search indexes. This is highly installation specific, and will be dependent on the repository formats used, the number of artifacts stored, the size of your teams and projects, etc. It's best to plan for a lot though, formats like Docker and Maven can use very large amounts of storage (500GB easily).

File Systems

Nexus Repository stores multiple kinds of data, with two primary storage requirements:

Embedded data (H2, OrientDB, Elastic Search) requires very responsive, fast storage, ideally local disk
Blob storage (component binaries), which requires moderately responsive, high-capacity storage

File system selection should be made bearing both of these in mind.

File System	Embedded data	Blob Stores	Comment
Local storage	Supported	Supported	Local storage is a good choice for both embedded data and binary storage.
NFS v4	Not Recommended (See Comment)	Supported	Most common protocol for network attached storage among Nexus Repository deployments. NFSv4.1 or higher can be used for the work directory in small lightly loaded installations, but we have found that it does not provide sufficient performance for anything larger. In general it should be avoided for the work directory.
Amazon EBS	Supported	Supported	EBS is a viable choice for both embedded data and binary storage.
Amazon EFS	Unsupported	Supported (See Comment)	EFS isn't sufficiently responsive for embedded data, but is appropriate for binary storage. EFS binary storage may not provide necessary throughput for heavy workloads in all configurations.
Amazon S3	N/A	Supported	S3 semantics aren't suitable for embedded data, but S3 is popular for binary storage.
SMB, CIFS	Unsupported	Supported	Problems are common with SMB or CIFS-mounted devices for embedded data.
Azure Blob Storage	N/A	Supported	Available for blob storage from Nexus 3.30.0 Pro. We support the premium performance block blob option. For performance reasons, the Azure blob store should be in the same Azure region as the Nexus Repo installation.
Azure Files	Unsupported	Supported	Issues with file handles have been observed when accessing embedded data over SMB.
S3-Compatible	Unsupported	Supported (See Comment)	Any fully compatible S3 implementation that supports the AWS SDK version 1.12.299 can be used as a blob store. Note that performance characteristics may differ from AWS S3; we recommend working with your vendor to ensure sufficient performance for your desired workload.
NFS v3	Unsupported		Numerous customers have experienced inadequate performance with NFS v3.
GlusterFS	Unsupported		Split-brain problems and slow performance are common.
FUSE	Unsupported		FUSE based user-space filesystems are known to be unreliable for Nexus Repository.

File System Optimization

We also have some optimization suggestions to use at your discretion. Also consider the noatime option for your Nexus Repository work directory mounts and limit the symbolic links used as this will cause increased overhead whenever paths need to be resolved to an absolute file path.

Web Browser

Our general policy is to support the most recent modern browser version for your supported OS at time of NXRM release date.

Vendor	Browser	Versions
Google	Chrome	latest at NXRM release
Mozilla	Firefox	latest and ESR* at NXRM release
Apple	Safari	latest at NXRM release
Microsoft	Edge	latest at NXRM release
Microsoft	Internet Explorer	No longer supported

* There is a known issue with uploading licenses using Firefox ESR.