Skip to main content

Sonatype Nexus Repository System Requirements

This topic covers system requirements for the Sonatype 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, and MacOS operating 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 root user.

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

Supported Java Versions

Sonatype Nexus Repository is tested on and supports OpenJDK.

As of release 3.71.0, Nexus Repository requires Java 17.

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.

CPU

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.

Memory Requirements

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 Recommendation by Profile Size

Profile Size

Profile Description

CPUs

RAM

Local Blob Storage

Small

Architecture 1

20,000 requests/hour

200,000 requests/day

embedded H2 database

2

8GB

20GB

Medium

Architecture 2

100,000 requests/hour

1,000,000 requests/day

external PostgreSQL database

2

8GB

200GB

Large

Architecture 3

1,000,000 requests/hour

10,000,000 requests/day

external PostgreSQL database

High Availability deployment

4 per node

16GB per node

200GB or more

Very Large

Architecture 4

2,000,000 requests/hour

20,000,000 requests/day

external PostgreSQL database

High Availability deployment

8 per node

32GB per node

10TB or more

Database Requirements

Sonatype Nexus Repository supports two database options: an embedded H2 database or an external PostgreSQL database.

Important

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.

You will need to remain on the 3.70.x version if you are unable to migrate from OrientDB. Versions 3.71.0 and above do not support OrientDB.

PostgreSQL Recommendation by Profile Size

Profile Size

Profile Description

CPUs

RAM

Disk Size

Small

Architecture 1

20,000 requests/hour

200,000 requests/day

External PostgreSQL database

2

8GB

200GB+

Medium

Architecture 2

100,000 requests/hour

1,000,000 requests/day

2-node PostgreSQL cluster

4 per node

32GB

500GB+

Large

Architecture 3

1,000,000 requests/hour

10,000,000 requests/day

2-node PostgreSQL cluster

16 per node

128GB

1TB+

Very Large

Architecture 4

2,000,000 requests/hour

20,000,000 requests/day

2-node PostgreSQL cluster

32 per node

256GB

1.5TB+

H2 Requirements

New installations use an H2 database by default.

Nexus Repository supports 20,000 requests per day / 100,000 components in H2 deployments. Workloads beyond these limitations are not supported. Container-based deployments are not supported in H2 deployments.

Disk Space Requirements

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

File Systems

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

Embedded data

Blob Stores

Local storage

A good choice for both embedded data and binary storage.

(tick)

Supported

(tick)

Supported

NFS v4

A common protocol for network-attached storage among Nexus Repository deployments.

Use NFSv4.1 or higher for the work directory in small deployments. It's not sufficient for anything larger.

(error)

Not Recommended

(tick)

Supported

Amazon EBS

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

(tick)

Supported

(tick)

Supported

Amazon EFS

EFS isn't sufficiently responsive for embedded data but is appropriate for binary storage.

EFS binary storage may not provide the necessary throughput for heavy workloads in all configurations.

(error)

Unsupported

(tick)

Supported

Amazon S3

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

(error)

Unsupported

(tick)

Supported

SMB, CIFS

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

(error)

Unsupported

(tick)

Supported

Azure Blob Storage

Available for blob storage from Nexus 3.30.0 Pro.

We support the premium performance block blob option.

(error)

Unsupported

(tick)

Supported

Azure Files

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

(error)

Unsupported

(tick)

Supported

S3-Compatible

Fully compatible S3 implementation that supports the AWS SDK version 1.12.658 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.

(error)

Unsupported

(tick)

Supported

Google Cloud Storage

Available for blob storage from Nexus 3.74.0 Pro.

(error)

Unsupported

(tick)

Supported

Google Cloud Filestore

Available for embedded data from Pro Version 3.74.0

(tick)

Supported

(error)

Unsupported

NFS v3

Numerous customers have experienced inadequate performance with NFS v3.

(error)

Unsupported

GlusterFS

Split-brain problems and slow performance are common.

(error)

Unsupported

FUSE

FUSE-based user-space filesystems are known to be unreliable for Nexus Repository.

(error)

Unsupported

File System Optimization

We have optimization suggestions to use at your 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.