Nexus Repository Editions, Deployment Models, Architecture, Installation, and Java Runtime Planning: Guided Hands-On Workflow and Core Operations

1. Preflight: prove the environment before installing

The lab baseline is the officially downloadable 3.94.1-06 archive. If the download page has moved to a newer release when you run the lesson, stop and read that release's notes/known issues first; either update the whole lab deliberately or obtain 3.94.1-06 from the official archive page. Do not mix a different launcher/runtime with assumptions written for this baseline.

mkdir -p "$HOME/nexus-ch02-lab/evidence"
cd "$HOME/nexus-ch02-lab"
printf 'Lab date (UTC): '; date -u
uname -a | tee evidence/01-os.txt
getconf LONG_BIT 2>/dev/null | tee evidence/02-bits.txt || true
ulimit -n | tee evidence/03-file-limit.txt
df -h . | tee evidence/04-disk.txt
free -h 2>/dev/null | tee evidence/05-memory.txt || true

# Current Sonatype small-profile guidance starts at 8 GiB RAM.
# Stop if the host cannot safely provide the required resources.

Download the appropriate 3.94.1-06 Community archive from Sonatype's official download/archive page using your browser. Verify the published checksum from that page before extraction. Record only the archive filename and checksum—not browser cookies or account data—in evidence.

2. Extract into a disposable parent directory

Sonatype's archive layout creates a versioned application directory and a sibling sonatype-work directory. Keeping the entire experiment under one known lab parent makes cleanup auditable. The command below assumes the downloaded Unix/Linux archive has been copied to the lab directory and named nexus-3.94.1-06.tar.gz for convenience; rename your verified official archive locally if its platform filename differs.

cd "$HOME/nexus-ch02-lab"
test -f nexus-3.94.1-06.tar.gz
mkdir -p instance
cd instance
tar xvz --keep-directory-symlink -f ../nexus-3.94.1-06.tar.gz

NX_INSTALL="$(find "$PWD" -maxdepth 1 -type d -name 'nexus-*' -print -quit)"
test -n "$NX_INSTALL"
NX_DATA="$PWD/sonatype-work/nexus3"
printf 'install=%s\ndata=%s\n' "$NX_INSTALL" "$NX_DATA" | tee ../evidence/06-paths.txt
ls -ld "$NX_INSTALL" "$PWD/sonatype-work" | tee ../evidence/07-layout.txt

Do not pre-create or copy database/blob internals. Nexus creates the data tree on first start. The application directory is versioned software; the sibling work directory becomes instance state.

3. Preconfigure loopback exposure in the data directory

The distribution's defaults can listen on all interfaces. For this disposable lab, create $data-dir/etc/nexus.properties before first start and override the connector to loopback. Current runtime guidance says custom application properties belong in the data directory; do not edit $install-dir/etc/nexus-default.properties.

mkdir -p "$NX_DATA/etc"
cat > "$NX_DATA/etc/nexus.properties" <<'EOF'
application-host=127.0.0.1
application-port=8081
nexus-context-path=/
EOF
chmod 600 "$NX_DATA/etc/nexus.properties"
cat "$NX_DATA/etc/nexus.properties" | tee ../evidence/08-nexus-properties.txt

The three settings mean: accept IPv4 loopback connections only; use port 8081; expose Nexus at the root context path. This protects the training bootstrap from accidental LAN/public exposure. Production designs usually place Nexus behind an explicitly configured reverse proxy/TLS boundary instead.

4. Start in the foreground as the disposable non-root user

For a local learning run, foreground mode makes ownership and logs easy to observe. Never launch the Nexus Java process with sudo. If the lab account owns the extracted tree, use that account.

# Terminal A
cd "$NX_INSTALL/bin"
./nexus run

# Keep this terminal open. Wait for startup to complete.

In a second terminal, rebuild the variables from the same known lab path and inspect rather than guessing:

# Terminal B
cd "$HOME/nexus-ch02-lab/instance"
NX_INSTALL="$(find "$PWD" -maxdepth 1 -type d -name 'nexus-*' -print -quit)"
NX_DATA="$PWD/sonatype-work/nexus3"
NX_URL=http://127.0.0.1:8081

curl -sS -o /dev/null -w 'read=%{http_code}\n' "$NX_URL/service/rest/v1/status" | tee ../evidence/09-status.txt
curl -sS -o /dev/null -w 'writable=%{http_code}\n' "$NX_URL/service/rest/v1/status/writable" | tee -a ../evidence/09-status.txt
ps -eo user,pid,ppid,args | grep '[n]exus' | tee ../evidence/10-process.txt
ss -ltnp 2>/dev/null | grep ':8081' | tee ../evidence/11-listener.txt || true
find "$NX_DATA" -maxdepth 2 -type d -printf '%P\n' 2>/dev/null | sort | tee ../evidence/12-data-dirs.txt
ls -lh "$NX_DATA/log" | tee ../evidence/13-logs.txt

Expected causal chain: the launcher starts the bundled/current supported Java runtime; the process writes the data tree; H2 is initialized as the default metadata store; the default local blob store is created for repository bytes; log files appear under the data tree; Jetty opens the configured loopback listener; the status endpoints become 200 when ready.

5. Bootstrap administration without logging the secret

On first start, Nexus writes a generated password to $NX_DATA/admin.password. That file is sensitive. Do not cat it into a transcript, pipe it through tee, include it in the evidence packet, or pass it on a command line. Open the UI at http://127.0.0.1:8081/, sign in as admin, and read the password locally in a protected manner only for the bootstrap interaction.

Complete the Community Edition onboarding wizard, including the current CE EULA acceptance step, set a unique disposable lab-only admin password, and choose anonymous-access behavior deliberately. For this chapter, disabling anonymous access makes later authorization observations easier. Store the lab password only in a temporary password manager entry or protected shell input—not in the lesson directory.

6. Inspect the exact runtime and storage mode

Open Settings → Support → System Information. Record the Nexus version, Java/runtime details, install directory, work/data directory, application host and port, and OS. Record those fields manually into evidence/14-system-summary.txt; do not blindly copy every environment variable because support/system bundles can contain operational secrets.

cd "$HOME/nexus-ch02-lab/instance"
NX_DATA="$PWD/sonatype-work/nexus3"

# Read-only filesystem evidence. Do not edit anything below db/blobs directly.
find "$NX_DATA" -maxdepth 2 -type d -printf '%P\n' 2>/dev/null | sort | tee ../evidence/15-state-map.txt
find "$NX_DATA" -maxdepth 2 -type f -printf '%P\t%s bytes\n' 2>/dev/null   | sort | head -80 | tee ../evidence/16-state-files.txt

grep -E 'Started|Java|H2|datastore|blob|port|Nexus Repository' "$NX_DATA/log/nexus.log"   | tail -80 | sed -E 's/(password|token|secret)=[^ ]+/\1=[REDACTED]/Ig'   | tee ../evidence/17-startup-extract.txt

Interpretation matters more than filenames. The database is structured metadata; blob directories are payload storage; logs are evidence; temporary files are runtime scratch space. None of those should be “repaired” by direct deletion because a directory looks large.

7. Stop and restart cleanly, then prove persistence

In Terminal A, interrupt foreground mode cleanly with Ctrl+C and wait for shutdown. Record that port 8081 closes. Then start ./nexus run again and verify the same instance state returns.

# Terminal B, after clean shutdown
curl -sS --max-time 2 -o /dev/null -w 'after-stop=%{http_code}\n'   http://127.0.0.1:8081/service/rest/v1/status 2>&1 | tee ../evidence/18-after-stop.txt || true

# After restarting in Terminal A:
curl -sS -o /dev/null -w 'after-restart=%{http_code}\n'   http://127.0.0.1:8081/service/rest/v1/status | tee ../evidence/19-after-restart.txt

Sign in using the disposable password chosen during onboarding. The fact that your security choice and repository configuration survived proves that persistent state lives outside the transient Java process. It does not by itself prove backup/recovery; that comes later in the course.

8. Windows-equivalent inspection

Windows uses the Windows archive and launcher, but the conceptual boundaries stay identical. Run Nexus from an ordinary disposable account rather than an elevated Administrator shell when possible, keep the data tree on a local supported filesystem, and use PowerShell for evidence.

$NxUrl = 'http://127.0.0.1:8081'
(Invoke-WebRequest "$NxUrl/service/rest/v1/status" -UseBasicParsing).StatusCode
Get-Process -Name java,nexus* -ErrorAction SilentlyContinue | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -LocalPort 8081 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess
Get-PSDrive -PSProvider FileSystem | Select-Object Name,Free,Used

9. Challenge: choose the layer, not the command

Suppose the UI is healthy after restart, but a teammate asks you to “move Nexus to a bigger disk” because blob usage is growing. Which state should you change?

Your answer should reject three shortcuts: moving the versioned install directory does not relocate repository bytes; copying only the H2 database does not move blob content; manually dragging internal blob directories while Nexus is live is not a supported migration plan. Identify the blob/data/storage layer involved, stop and consult the current storage/migration documentation, preserve database↔blob consistency, and plan rollback before mutation. Chapter 05 will implement storage design in depth.

Knowledge check

10. Summary

You installed a pinned Community instance as a stateful service, kept it on loopback, separated replaceable application files from durable data, observed H2/local-blob state, protected bootstrap credentials, and proved restart persistence. The next lesson turns those mechanics into explicit architecture choices.

Official references and version notes

• Download Nexus Repository — official current download page; at review time it presents 3.94.1 as the downloadable self-hosted release.
• Nexus Repository 3.95.0 release notes — official release notes state that 3.95.0 was released August 5, 2026; this is intentionally called out because the download/version indexes can lag.
• Nexus Repository system requirements — supported operating systems, dedicated-user guidance, file handles, Java 21, memory, H2 limits, and PostgreSQL requirements.
• Java Runtime Compatibility Matrix — Java 21 is the supported runtime for H2/PostgreSQL Nexus Repository 3.87.0 and later.
• Install Self-Hosted Nexus Repository — archive installation, default H2/local blob behavior, initial admin state, and deployment planning.
• Configuring the Runtime Environment — install-dir versus data-dir configuration, nexus.vmoptions, nexus.properties, port, context path, logs, and temporary state.
• Nexus Repository Database — embedded H2 versus external PostgreSQL usage boundaries.
• Install Nexus Repository with PostgreSQL — supported external PostgreSQL setup and Nexus datastore configuration.
• Self-Hosted Nexus Repository Feature Matrix — current Community Edition versus Professional capability boundaries.
• Community Edition Onboarding — current CE onboarding/EULA workflow and 40,000-component / 100,000-request-per-day usage limits.
• Usage Center — current Community Edition usage-limit behavior and operational monitoring.
• Status API — current readiness, writable-state, and authenticated status-check endpoints.
• System Information — read-only server evidence including version, install/work directories, host/port, JVM, OS, and runtime details.
• Run as a Service — dedicated process identity, service configuration, and supported runtime override mechanisms.

Version-sensitive statements were rechecked against Sonatype primary documentation on 2026-08-26. The mandatory path remains self-hosted, Community/free-compatible, and disposable; production credentials, production repositories, and paid-only capabilities are outside the lab boundary.