Skip to content

Deploying a Nexus3 App

Introduction

Nexus Repository Manager 3 (Nexus3) hosts Maven, npm, Docker, PyPI, and other artifacts. Deploying Nexus3 with a Dockerfile on Klutch.sh provides reproducible builds, managed secrets, and persistent storage for repositories—all configured from klutch.sh/app. This guide covers installation, repository prep, a production-ready Dockerfile, deployment steps, Nixpacks overrides, sample API usage, and production tips.


Prerequisites

  • A Klutch.sh account (sign up)
  • A GitHub repository containing your Nexus3 Dockerfile (GitHub is the only supported git source)
  • Storage sizing for hosted/proxy repos
  • Optional SMTP credentials for notifications

For onboarding, see the Quick Start.


Architecture and ports

  • Nexus3 serves HTTP on internal port 8081; choose HTTP traffic.
  • Persistent storage is required for blob stores, config, and logs.

Repository layout

nexus3/
├── Dockerfile # Must be at repo root for auto-detection
└── README.md

Keep admin credentials out of Git; store them in Klutch.sh environment variables.


Installation (local) and starter commands

Validate locally before pushing to GitHub:

Terminal window
docker build -t nexus3-local .
docker run -p 8081:8081 nexus3-local

Dockerfile for Nexus3 (production-ready)

Place this Dockerfile at the repo root; Klutch.sh auto-detects it (no Docker selection in the UI):

FROM sonatype/nexus3:3.66.0
ENV NEXUS_CONTEXT="" \
NEXUS_SECURITY_RANDOMPASSWORD=false
EXPOSE 8081
CMD ["bin/nexus", "run"]

Notes:

  • Pin the image tag (e.g., 3.66.x) for stability and upgrade intentionally.
  • NEXUS_CONTEXT lets you serve under a path; empty means root.
  • Disable random admin password to set your own; otherwise fetch it from /nexus-data/admin.password.

Environment variables (Klutch.sh)

Set these in Klutch.sh before deploying:

  • NEXUS_CONTEXT= (blank for root, or set a path)
  • NEXUS_SECURITY_RANDOMPASSWORD=false
  • Optional JVM tuning: INSTALL4J_ADD_VM_PARAMS=-Xms1200m -Xmx1200m -XX:MaxDirectMemorySize=2g
  • Optional SMTP: NEXUS_SMTP_HOST, NEXUS_SMTP_PORT, NEXUS_SMTP_USER, NEXUS_SMTP_PASSWORD, NEXUS_SMTP_FROM

If you deploy without the Dockerfile and need Nixpacks overrides:

  • NIXPACKS_START_CMD=bin/nexus run

Attach persistent volumes

In Klutch.sh storage settings, add mount paths and sizes (no names required):

  • /nexus-data — blob stores, configuration, and logs.

Ensure this directory is writable.


Deploy Nexus3 on Klutch.sh (Dockerfile workflow)

  1. Push your repository—with the Dockerfile at the root—to GitHub.
  2. Open klutch.sh/app, create a project, and add an app.
  3. Select HTTP traffic and set the internal port to 8081.
  4. Add the environment variables above, including context path and JVM tuning if needed.
  5. Attach a persistent volume for /nexus-data sized for your repositories and logs.
  6. Deploy. Access Nexus3 at https://example-app.klutch.sh (or with your context path).

Sample API usage

Get system status (replace admin credentials):

Terminal window
curl -u "admin:<password>" \
-X GET "https://example-app.klutch.sh/service/rest/v1/status"

Create a raw hosted repository via API:

Terminal window
curl -u "admin:<password>" \
-X POST "https://example-app.klutch.sh/service/rest/v1/repositories/raw/hosted" \
-H "Content-Type: application/json" \
-d '{"name":"raw-hosted","online":true,"storage":{"blobStoreName":"default","strictContentTypeValidation":true}}'

Health checks and production tips

  • Add an HTTP probe to / or /service/rest/v1/status for readiness.
  • Enforce HTTPS at the edge; forward internally to port 8081.
  • Keep admin and SMTP credentials in Klutch.sh secrets; rotate them regularly.
  • Monitor /nexus-data usage; resize before it fills.
  • Pin image versions and back up /nexus-data before upgrades; test in staging first.

Nexus3 on Klutch.sh combines reproducible Docker builds with managed secrets, persistent storage, and flexible HTTP/TCP routing. With the Dockerfile at the repo root, port 8081 configured, and data persisted, you can host artifacts securely without extra YAML or workflow overhead.