# High Availability Deployment

Only available in Sonatype Nexus RepositoryTM Pro. Interested in a free trial? [Start here](/content/products/repository-pro/trial/index.html).

High availability (HA) refers to a system's ability to operate continuously with minimum downtime. It's about ensuring that critical systems and applications are accessible and reliable, even in the face of unexpected events or failures.

## Overview

Nexus Repository accomplishes HA by deploying a cluster of redundant instances, or nodes, running simultaneously within a single data center. This model improves uptime as at least one node of Nexus Repository is available to receive requests in the event that other instances are unavailable.

See [Requirements for High Availability](https://help.sonatype.com/en/system-requirements-for-high-availability-deployments.html "Requirements for High Availability")

- #### Application Load Balancer

The Nexus Repository nodes are behind an application load balancer that monitors the availability of the nodes and distributes requests to available instances.

- #### Shared External PostgreSQL Database

The instances connect to a shared external database on separate hardware and managed independently from Nexus Repository.

- #### Shared Object Blob Storage

Components are stored in shared blob stores located on network storage or object-based storage. Each instance requires low-latency access to the shared storage.

- #### Nexus Repository Instances

Each Nexus Repository instance should run on separate hardware to avoid losing multiple nodes due to a single point of failure. A minimum of two nodes are required for HA deployments.

Additional nodes provide extra redundancy to handle more capacity to allow for scaling of the cluster. Keep in mind that the network's bandwidth and the database's hardware are the limiting factors as you scale up the number of nodes in a cluster.

## Related Topics

- #### Install in HA deployment using the OpenShift Operator

Follow the steps outlined in the OpenShift Operator documentation.  
  See [OpenShift Operator](https://help.sonatype.com/en/install-nexus-repository-on-openshift.html "Install Nexus Repository on OpenShift").

- #### Migrating from the Legacy HA-C deployment

Follow the instructions for migrating from a Legacy HA-C Deployment KB article.  
  See [Migrating from a Legacy HA-C Deployment](https://support.sonatype.com/hc/en-us/articles/44146407877395-Migrating-from-Legacy-HA-C)

- #### Upgrades in an HA environment

Nexus Repository 3.71.0 supports zero downtime upgrades. For details, see our help topic on upgrading Nexus Repository using rolling upgrades.

- #### Updating to the helm chart with shared logging

As of Nexus Repository 3.68.0, the Helm chart uses a shared logging location.

- #### Content selector difference in an HA environment

Learn the differences in how content selectors work in HA deployments.  
  See [Content Selectors](https://help.sonatype.com/en/content-selectors.html#content-selectors-in-high-availability "Content Selectors in High Availability")

- #### SQL Search

While all Nexus Repository instances on versions 3.88.0 and beyond use SQL search, earlier versions used Elasticsearch for standalone instances and SQL search in HA environments. If you are migrating to HA in versions before 3.88.0, make sure to learn the differences you can expect in search behavior.
  See [SQL Search](https://help.sonatype.com/en/sql-search.html "SQL Search")

- #### Default blob store

Enabling HA removes the default blob stores on new instances. Review the follow the instructions to change your default blob stores to a shared location.  
  See [Moving Blob Storage](https://help.sonatype.com/en/blob-stores.html#moving-a-blob-store "Moving a Blob Store")