Skip to main content

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 the lines like below to this file where <userid> is the user ID you are using to run Sonatype Nexus Repository:

<userid> - nofile 65536
<userid> - nproc 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
LimitNPROC=65536
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
  1. 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.

  2. 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)
  1. 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.

  2. 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.

See Instance Resource Sizing Profiles for suggested CPU configurations by deployment profile.

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 Resource 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

Note

-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 Profile

Database memory tuning example with values calculated based on the small profile defined in Instance Resource Sizing Profiles.

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

Database memory tuning example with values calculated based on the medium profile defined in Instance Resource Sizing Profiles.

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

Database memory tuning example with values calculated based on the large profile defined in Instance Resource Sizing Profiles.

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

Note

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 instance to a PostgreSQL database.

Note

Notable Compatibility Change for H2 or PostgreSQL Database Deployments

In Sonatype Nexus Repository release 3.43.0, we added compatibility with official NuGet v2 clients. The supported subset of the legacy NuGet v2 protocol is the same as that supported by Microsoft's NuGet Gallery, nuget.org. Use cases that rely on the deprecated parts of the v2 API are not supported, including many common Chocolatey use cases and some custom OData queries.

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

Warning

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:

  1. Embedded data (H2, OrientDB, Elastic Search) requires very responsive, fast storage, ideally local disk

  2. 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

(tick)

Supported

(tick)

Supported

Local storage is a good choice for both embedded data and binary storage.

NFS v4

(error)

Not Recommended

(See Comment)

(tick)

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

(tick)

Supported

(tick)

Supported

EBS is a viable choice for both embedded data and binary storage.

Amazon EFS

(error)

Unsupported

(tick)

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

(tick)

Supported

S3 semantics aren't suitable for embedded data, but S3 is popular for binary storage.

SMB, CIFS

(error)

Unsupported

(tick)

Supported

Problems are common with SMB or CIFS-mounted devices for embedded data.

Azure Blob Storage

N/A

(tick)

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

(error)

Unsupported

(tick)

Supported

Issues with file handles have been observed when accessing embedded data over SMB.

S3-Compatible

(error)

Unsupported

(tick)

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

(error)

Unsupported

Numerous customers have experienced inadequate performance with NFS v3.

GlusterFS

(error)

Unsupported

Split-brain problems and slow performance are common.

FUSE

(error)

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

Note

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