# sonatype/docker-nexus3: Docker Deployment and Image Choices

> sonatype/docker-nexus3 packages Sonatype Nexus Repository Manager 3 for teams that need a central service for binaries, components, and packages. It offers Docker and Compose deployment paths, multiple Linux image variants, and persistent storage through `/nexus-data`, but its documentation leaves several production concerns open.

**sonatype/docker-nexus3** — Dockerized version of Nexus Repo Manager 3

- Repository: https://github.com/sonatype/docker-nexus3
- Stars: 1,652 · Forks: 587
- Language: Groovy
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/sonatype-docker-nexus3

## What sonatype/docker-nexus3 centralizes

sonatype/docker-nexus3 is Sonatype's container packaging project for Nexus Repository Manager 3. It addresses the operational problem of distributing internal and third-party binaries, components, and packages through separate locations. The README calls Nexus Repository a single source of truth and says it can connect development tools to a centralized binary repository. The intended users are therefore software teams that host artifacts for builds, CI systems, or developers working across multiple machines.

This repository does not implement a new package format or provide a second repository manager. It packages the Nexus Repository Manager application and prepares it for execution inside a Docker container. Repository formats, access policies, edition limits, and most application settings remain the responsibility of Nexus Repository itself. A Docker tag can make deployment convenient without changing those application-level constraints.

The README says the free product became Sonatype Nexus Repository Community Edition in version 3.77.0. It describes Community Edition as intended for individual users and small teams and explicitly notes usage limitations. The README links to separate Community Edition documentation rather than listing every restriction in this container project. Operators must consult that product documentation before assuming that an internal, organizational, or high-volume use case fits the free edition.

The repository is not archived. Its last push was on 2026-10-14, which establishes recent repository activity but does not say how long individual image tags receive support. The listed release `3.13.0-02` dates to 2018-08-29, while the README discusses image behavior beginning with version 3.91.0. This difference means the visible release list should not be treated as a complete inventory of available container versions.

## Docker image architecture and application layers

The repository uses multiple Dockerfiles to support different base images and deployment environments. `Dockerfile.java21` corresponds to the UBI-based variant. `Dockerfile.alpine.java21` corresponds to the default Alpine variant described from version 3.91.0. Red Hat-oriented builds have separate files: `Dockerfile.rh.ubi.java21`, `Dockerfile.rh.el`, and `Dockerfile.rh.centos`.

According to the README, Chef Solo builds the runtime and application layers. The associated cookbook is maintained in the separate `sonatype/chef-nexus-repository-manager` repository. This division places the container build process in sonatype/docker-nexus3 while keeping cookbook logic in its named source repository. The repository also includes `solo.json.erb`, a Jenkinsfile, and scripts under `scripts/`, which show that the image is assembled through an organized build process rather than a single application startup script alone.

The service listens on port 8081. The Compose configuration maps that port to the host and mounts a named volume at `/nexus-data`. That mount is the most important runtime boundary visible in the repository configuration. Data placed under `/nexus-data` remains in the named volume when the container is replaced, provided the operator does not remove that volume. Data in other container paths may be tied to the container lifecycle.

The README describes an ENTRYPOINT script that ensures the application runs with the permissions it needs. For the Red Hat certified image, it says the script helps ensure access to the permissions required by OpenShift's `restricted` SCC. This indicates that ownership and permission handling are part of container startup, not just image construction. The README does not expose the complete startup sequence or enumerate every environment variable used by that script.

## Starting and stopping the documented container

The first documented deployment uses the default image directly. Docker starts it in the background, binds host port 8081 to container port 8081, and assigns the name `nexus`.

```bash
docker run -d -p 8081:8081 --name nexus sonatype/nexus3
```

The README suggests a request to the exposed endpoint after startup. This checks whether something is listening and responding on the mapped port.

```bash
curl http://localhost:8081/
```

The README does not define the expected response body or a readiness condition that confirms every repository subsystem has finished initialization. A service can accept a connection before all hosted repositories are ready. Operators therefore need to distinguish port availability from application readiness, although this repository does not prescribe a health-check command.

Shutdown has an explicit database consideration. The README says to allow sufficient time for the databases to shut down and provides a command with a 120-second timeout.

```bash
docker stop --time=120 <CONTAINER_NAME>
```

Here, `<CONTAINER_NAME>` is a documented placeholder. It should be replaced with the actual name, such as `nexus` when the first-run command was used. The repository does not explain the internal database engines or demonstrate recovery from an interrupted stop. Ignoring the stated shutdown interval therefore adds operational risk to a service whose state is stored under `/nexus-data`.

## Persistent Docker Compose deployment

The repository's `docker-compose.yml` provides a second deployment path. Instead of defining a standalone container command, it declares a `nexus` service, maps port 8081, and attaches the named `nexus-data` volume to `/nexus-data`.

```yaml
version: "2"

services:
  nexus:
    image: sonatype/nexus3
    volumes:
      - "nexus-data:/nexus-data"
    ports:
      - "8081:8081"

volumes:
  nexus-data: {}
```

This arrangement preserves data outside the container's writable layer. That matters when a container is stopped, replaced, or rebuilt. It does not, by itself, protect against loss of the Docker volume or failure of its storage backend. The file does not configure a backup destination, retention policy, replication target, or restore procedure.

The Compose example also leaves `image` as the unqualified `sonatype/nexus3` reference. The README separately lists specific Alpine and UBI tags, but this file does not select one. A deployment that requires repeatable versions must decide how tags will be recorded and controlled. The README does not provide a policy for automatic updates, tag pinning, or rollback.

Several other production settings are absent from this file. There is no health check, resource limit, restart rule, reverse proxy, TLS setting, or environment-variable configuration. Their absence does not prove that Nexus cannot use them. It means the supplied Compose example is a basic deployment definition rather than a complete production configuration. The README also does not document how to scale this Compose service across multiple hosts.

## Choosing Alpine, UBI, and Red Hat images

The base image is a concrete compatibility choice. The README identifies the Alpine-based image as the default from version 3.91.0 and states that it is intended to minimize dependencies. It lists a rolling tag, version-specific tags, and an explicit Alpine tag form.

```text
sonatype/nexus3:latest
sonatype/nexus3:3.XX.y
sonatype/nexus3:3.XX.y-alpine
```

For a UBI-based deployment, the README documents the `-ubi` suffix and associates the build with `Dockerfile.java21`.

```text
sonatype/nexus3:3.XX.y-ubi
```

The README says both listed Alpine and UBI forms run Java 21. It does not publish a comparative table for image size, startup time, memory consumption, package compatibility, or security updates. Those claims should not be inferred from the Alpine description alone.

A separate Red Hat certified image can be built from `Dockerfile.rh.ubi.java21`. According to the README, it includes metadata for Kubernetes and OpenShift, a directory of applicable licenses, a man file, and an entrypoint for permission handling. Qualified accounts can pull it from `registry.connect.redhat.com`. The README also identifies Red Hat Enterprise Linux and CentOS build files, but it does not say whether those builds receive the same certification or update schedule as the certified UBI image.

For custom image builds, the README lists `NEXUS_VERSION`, `NEXUS_DOWNLOAD_URL`, and `NEXUS_DOWNLOAD_SHA256_HASH`. The hash is required when either of the first two variables is provided. This supports explicit verification of a downloaded Nexus archive, but the README does not provide a complete command that sets all three build arguments.

## Custom image builds and release maintenance

Contributors can build the image from the repository directory using the primary `Dockerfile`. The documented command discards the intermediate build container and assigns the local image tag `sonatype/nexus3`.

```bash
docker build --rm=true --tag=sonatype/nexus3 .
```

The repository documents `rspec` as its test framework. It says `serverspec` supplies a Docker backend and abstracts differences between distributions in the tests. The documented test target is `spec/Dockerfile_spec.rb`.

```bash
rspec [--backtrace] spec/Dockerfile_spec.rb
```

The README presents `rspec [--backtrace] spec/Dockerfile_spec.rb` as the general form rather than specifying whether `--backtrace` is always passed. It does not document the prerequisites needed to run the suite in a clean environment.

Maintenance work includes more than rebuilding an image. An upgrade can change the base image, Java runtime, Nexus archive, Chef Solo cookbook, entrypoint behavior, or metadata. The README links to the cookbook repository but does not describe a coordinated upgrade process across the two repositories. It also does not document rollback to an earlier image tag or state whether existing `/nexus-data` can be restored after every version change.

The repository's Apache-2.0 license applies to this container project. The Dockerfile also contains an Apache License notice and a Sonatype attribution comment. The README refers to third-party code and points to Sonatype's attributions location. This repository does not enumerate the full licensing terms of each image variant or bundled application component, so distribution decisions require separate review. The last push was on 2026-10-14, but the README does not define a support window or patch commitment for any tag.

Compared with a manually managed host installation, this project moves packaging and startup into a versioned container definition. Compared with the direct `docker run` command, `docker-compose.yml` adds declarative service and volume management. The actual distinction is packaging control, not a change to the underlying Nexus Repository application.

## Conclusion

Adopt sonatype/docker-nexus3 when your team wants Sonatype Nexus Repository Manager 3 delivered as a container and can manage Docker volumes, ports, image versions, and shutdown timing. Do not treat the container filesystem as disposable storage or adopt the example configuration without deciding how `/nexus-data` will be retained and restored. Before deployment, verify the selected tag, edition limitations, network access controls, base-image requirement, and persistence arrangement. This repository offers a clear container starting point, while the README leaves rollback, backup, and upgrade procedures to separate documentation or operator policy.

## FAQ

### How do I run Sonatype Nexus Repository Manager 3 with Docker?

The README documents `docker run -d -p 8081:8081 --name nexus sonatype/nexus3`. It then suggests checking the exposed endpoint with `curl http://localhost:8081/`.

### Where should sonatype/docker-nexus3 store persistent data?

The repository's `docker-compose.yml` mounts the named `nexus-data` volume at `/nexus-data`. The README does not document backup, restore, or migration procedures for that volume.

### Which sonatype/nexus3 image variants are available?

The README identifies Alpine as the default family and documents UBI images using the `-ubi` tag suffix. It also identifies Red Hat, Enterprise Linux, and CentOS Dockerfile variants without giving a detailed compatibility comparison.

### How should I stop the sonatype/nexus3 container?

The README says to allow sufficient time for databases to shut down and gives `docker stop --time=120 <CONTAINER_NAME>`. The `<CONTAINER_NAME>` value must be replaced with the actual container name.

## Sources

- [Issues](https://github.com/sonatype/docker-nexus3/issues)
- [License: Apache-2.0](https://github.com/sonatype/docker-nexus3/blob/main/LICENSE)
- [README](https://github.com/sonatype/docker-nexus3/blob/main/README.md)
- [Releases](https://github.com/sonatype/docker-nexus3/releases)
- [sonatype/docker-nexus3 on GitHub](https://github.com/sonatype/docker-nexus3)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sonatype-docker-nexus3