Nexus Repository Editions, Deployment Models, Architecture, Installation, and Java Runtime Planning: Configuration, Design Choices, and Tradeoffs

1. Design from state and failure domains

A platform decision is useful only when it says what state moves, what can fail independently, who operates it, and how the service recovers. “Use Kubernetes because it scales” is not a Nexus design. “Use a VM because it is simple” is not a Nexus design either. Start with database, blobs, process runtime, network path, workload and recovery objectives, then choose an execution environment that can preserve those invariants.

2. Bundled runtime versus external Java

Current Nexus Repository releases require Java 21, and current official installers/images include a supported runtime. The bundled runtime reduces a compatibility variable: the Nexus package and JVM are tested as one release unit. An external JVM can be justified by organization runtime policy, but it becomes an explicit compatibility/patching responsibility.

Do not modify Java because “newer must be faster.” A runtime change can alter heap behavior, native/direct memory, TLS providers and metrics. Treat it like a platform upgrade with evidence and rollback.

3. H2 convenience versus PostgreSQL production suitability

H2 collapses database operations into the Nexus process. That makes a disposable lab easy but couples database availability and process lifecycle. Current support limits are explicit: up to 200,000 requests/day or 100,000 components, and no H2 container deployments. Crossing those boundaries is not a tuning challenge; it is a topology problem.

PostgreSQL separates metadata persistence from the Nexus JVM. It adds a networked service, credentials, backups, upgrades, connection capacity and latency concerns, but supports production deployment patterns that H2 does not. Sonatype currently recommends external PostgreSQL for deployments and requires the database user to own the database plus the pg_trgm extension.

Blob storage remains a separate decision. PostgreSQL does not “store all packages in SQL.” Nexus still uses blob stores for binary payloads, so backup and recovery must cover both sides consistently.

4. Bare metal/VM versus container/cloud-native

A container image is a packaging/runtime unit, not persistence. If the only copy of repository state is in a writable container layer, the design is broken even if restart automation is perfect.

5. Single node, resilient deployment, HA, and DR answer different questions

A single node minimizes moving parts and is ideal for learning and many small environments. It has an obvious availability limit: when that process/host is unavailable, the service is unavailable.

High availability and resilient deployment options introduce shared/consistent database and blob requirements, node coordination and load balancing. Current feature documentation marks HA/resilient deployment capabilities as Pro. They are not simulated by starting two independent Community nodes against unrelated state.

Backup/disaster recovery is separate from HA. Multiple live nodes cannot undo accidental deletion or logical corruption. A recoverable design needs validated backups and explicit RPO/RTO even if request availability is high.

6. License decisions should follow capability requirements

Do not select Pro because “production means paid,” and do not assume CE has no enterprise-useful controls. Current matrix gives CE external PostgreSQL, AWS S3 blob stores, LDAP, content selectors/custom access control, routing rules, REST/API coverage and more. Conversely, current Pro capabilities include HA/resiliency, SAML, user tokens, content replication, staging/build promotion and selected blob/storage capabilities.

The correct sequence is: define requirement → map it to a named current feature → check the feature matrix → record edition prerequisite → design a free/simulated learning equivalent when the feature is paid-only. Also model CE's current 40,000-component / 100,000-request-per-day usage limits separately from H2's current 100,000-component / 200,000-request-per-day database support limits; whichever bound you hit first governs the design.

7. Keep adjacent configuration in its own owner domain

8. Worked decision: 35 developers, internal packages, business-hours criticality

Scenario: one team has 35 developers, roughly 15,000 components, 45,000 requests/day, two package formats, an existing PostgreSQL service, no 24×7 availability target, and an RTO of four hours. They need LDAP and path-level authorization, but not SAML, HA, user tokens or content replication.

If the same organization later requires multi-node active availability, SAML and zero-downtime patterns, the architecture and edition decision change. That is evidence-driven evolution, not an admission that the first design was wrong.

Knowledge check

9. Summary

Architecture choices are contracts over state and failure domains. A supportable Nexus design states its runtime, database, blob topology, execution environment, edition entitlements, network boundary, recovery path, and the evidence that proves those choices remain true.

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.