Nexus Repository Editions, Deployment Models, Architecture, Installation, and Java Runtime Planning: Concepts, Architecture, and Mental Model

1. From repository concepts to a running service

Chapter 01 established the logical model: producers and consumers talk to protocol-aware repository endpoints; hosted repositories own internal artifacts; proxy repositories mediate upstreams; group repositories aggregate reads; components describe logical package identity while assets are the concrete files. Chapter 02 asks a different question: what must exist underneath those endpoints so that the service remains supportable after a reboot, upgrade, disk event, or operator change?

A repository manager is a stateful server, not a stateless web UI. Starting a Java process is only one layer. The server also depends on persistent metadata, blob bytes, runtime settings, filesystem permissions, database connectivity, network exposure, and an administrative bootstrap path. If those layers are confused, a seemingly harmless “move Nexus” or “replace the install directory” operation can destroy availability or make recovery ambiguous.

2. The five-state mental model

flowchart TD
CLIENT[Package client or browser] -->|HTTP or HTTPS| JETTY[Nexus web connector]
JETTY --> APP[Nexus application in Java 21 JVM]
APP --> DB[(Database metadata and configuration)]
APP --> BLOBS[(Blob stores: artifact bytes)]
APP --> LOGS[(Data-dir logs tasks temp)]
APP -->|proxy request when needed| UPSTREAM[Remote package registry]
IDENTITY[OS process identity] --> APP
INSTALL[Install directory plus bundled runtime] --> APP

Client → web connector: Maven, npm, curl, a browser, or CI sends a protocol request to an address and port. A bind address determines which local network interfaces accept that connection. The default application port is 8081; production exposure is normally placed behind a properly configured reverse proxy/TLS boundary rather than casually publishing the backend connector.

Install directory → application: the extracted distribution contains executables, libraries, default configuration, and current bundled runtime material. It is replaceable during an upgrade. Treat it as application software, not as the authoritative home of repository content.

Data directory → persistent service state: the work/data tree contains instance-specific configuration, logs, temporary/runtime state, and the default local data locations. With an archive install, the familiar default sibling is sonatype-work/nexus3. The exact effective path is authoritative; inspect it rather than assuming it.

Database → logical metadata: users, roles, repository configurations, search/index-related metadata, and other structured application state live in the supported database. Current new installations default to embedded H2. External PostgreSQL is Sonatype's preferred database for production deployments.

Blob stores → bytes: package files, archives, image layers, and other repository payloads are stored as blobs. Database rows and blob bytes form related state. A backup of only one side is not a complete recovery strategy.

3. Define the operating objects before touching them

4. H2 and PostgreSQL are deployment choices, not interchangeable files

H2 is an embedded relational database running in the same Java process as Nexus. It minimizes moving parts and is therefore useful for learning, evaluation, single-team and disposable workloads. Current Sonatype requirements cap supported H2 use at 200,000 requests per day or 100,000 components and explicitly state that container-based H2 deployments are unsupported.

PostgreSQL is external: Nexus connects over JDBC to a separate supported PostgreSQL service. Sonatype recommends it for deployments generally and requires/assumes it for several production-scale patterns. The database user must own the database, pg_trgm is required, and low database latency matters. Moving to PostgreSQL is not “copy the H2 file”; it is a supported datastore/migration workflow.

5. Community, Pro, self-hosted, and cloud are different boundaries

Self-hosted means your organization operates the Nexus Repository server and its persistence/network lifecycle. Nexus Repository Cloud is a managed offering with a different responsibility boundary; do not copy self-hosted filesystem or process procedures into a cloud tenant.

Community Edition (CE) is the free self-hosted path used for mandatory labs. Current feature documentation includes external PostgreSQL, AWS S3 blob stores, content selectors/custom access controls, LDAP, routing rules, REST/API coverage, component search, and backup/restore capabilities in CE. CE currently has usage limits of 40,000 total components or 100,000 requests per day; exceeding either pauses addition of new components until usage returns below both thresholds. Do not assume “enterprise-sounding” automatically means Pro, and do not confuse CE usage limits with the separate H2 database support limits.

Professional (Pro) adds capabilities that currently include high-availability/resilient deployment options, SAML, user tokens, staging/build promotion, content replication, import/export capabilities, and several cloud blob integrations. Those features are useful architecture context but are not required to complete this chapter.

6. Read-only inspection comes first

When you inherit a Nexus instance, first establish identity and health without changing configuration. The unauthenticated status endpoint tells you whether the application can serve reads; the writable endpoint tells you whether it can serve writes. They do not prove disk, external database, or upstream health by themselves.

NX_URL=http://127.0.0.1:8081
curl -sS -o /dev/null -w 'read-status=%{http_code}\n' "$NX_URL/service/rest/v1/status"
curl -sS -o /dev/null -w 'write-status=%{http_code}\n' "$NX_URL/service/rest/v1/status/writable"

# OS evidence; commands are read-only.
ps -eo user,pid,ppid,args | grep '[n]exus' || true
ss -ltnp 2>/dev/null | grep ':8081' || true
ulimit -n

df -h .

Then use Settings → Support → System Information with an appropriately privileged administrative account. It exposes Nexus version, installed plugins, install/work directory, application host/port, JVM properties/runtime, OS and environment details. Treat a downloaded System Information JSON as sensitive operational evidence: inspect and sanitize it before sharing.

Finally, read the main log and repository list/API with a least-privilege identity. Read-only evidence should answer “what process?”, “what version?”, “what listener?”, “what database mode?”, “what data path?”, “what repository topology?”, and “what recent errors?” before an operator changes any of them.

7. Trust boundaries exist below package authorization

The OS service user controls filesystem access. Nexus users/roles control application operations. Database credentials authorize metadata access. Remote-repository credentials authorize upstream calls. Reverse proxy/TLS configuration authenticates and protects network paths. These are separate credentials and failure domains.

The initial built-in admin account is a bootstrap mechanism, not a reusable CI identity. Its generated initial password is stored under the data directory. Do not print it into logs, screenshots, shell history, or evidence bundles. After bootstrap, administrative access should be minimized and automation should use scoped identities.

8. Why this matters in DevOps

A pipeline that depends on Nexus also depends on Nexus's supported runtime and persistent-state design. If the process runs as root, if the data directory is on an ephemeral disk, if H2 is pushed beyond supported limits, if blob bytes and database state cannot be restored consistently, or if the backend listener is exposed without a network boundary, “the package server is up” is a misleading success criterion.

Production reliability starts before repository traffic arrives: pin a supported release/runtime, choose database/blob topology deliberately, separate replaceable application files from durable state, use a dedicated process identity, bound network exposure, and capture evidence that operators can independently verify.

Knowledge check

9. Summary

A Nexus deployment is a layered stateful system: client endpoint, Java application, process identity, install directory, data directory, database, blob stores, logs/tasks, and optional upstream/identity/network services. Keeping those boundaries explicit prevents destructive administration and gives the next lesson a safe foundation for installation.

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.