Production Capstone: Design, Secure, Automate, Migrate, and Recover an Enterprise Artifact Platform: Final Operational Review and Handoff

1. Handoff criterion: another operator can run the platform

The capstone is complete only when the implementation is understandable without the original builder. A handoff must explain what exists, why it exists, how it is changed, how it is observed, what the failure domains are, how recovery works, and which decisions must be revisited as versions, workload, teams, and licensing change.

2. Final platform inventory

3. Production readiness checklist

• Repository hosted/proxy/group responsibilities are documented and client endpoints are unambiguous.
• Internal namespace ownership is explicit and direct-public bypass is governed.
• CI publishes only to hosted repositories with a dedicated least-privilege identity.
• Release identity records coordinate/version or digest, SHA-256, build ID, source commit, and publication evidence.
• Promotion moves/copies exact bytes; it does not rebuild source.
• Anonymous access, realms, roles, selectors, and service credentials are deliberate and negatively tested.
• TLS/reverse-proxy/client URLs are tested from the actual client path.
• Cleanup is previewed; logical deletion and physical reclamation are separate.
• Scheduled tasks have owners, windows, history, and concurrency awareness.
• Automation is idempotent, pagination-aware, version-schema-aware, and drift-governed.
• Supply-chain evidence types are not conflated; optional licensed policy is labeled.
• Database and blobs are backed up coherently and restores are rehearsed.
• Migration/upgrade changes satisfy exact source/target and crossed-version gates.
• HA, if purchased/required, uses supported shared state and does not replace backup.
• Logs/metrics/support evidence can diagnose client→Nexus→DB/blob/upstream paths without leaking secrets.
• Capacity trends and thresholds leave headroom for cleanup, upgrade, backup, and recovery operations.

4. Runbook set

runbooks/
  provision-reconcile.md
  publish-maven.md
  publish-npm.md
  promote-exact-artifact.md
  rotate-service-credential.md
  upstream-outage.md
  cleanup-preview-and-reclaim.md
  task-failure.md
  create-and-review-support-zip.md
  backup.md
  restore-validation.md
  database-migration.md
  nexus-upgrade.md
  ha-node-db-blob-failure.md       # optional Pro/HA architecture path
  firewall-policy-review.md        # optional licensed path
  capacity-threshold-response.md

Each runbook begins with preflight and scope, records version/edition assumptions, lists expected evidence, identifies destructive steps, defines rollback, and ends with verification.

5. Change ownership and emergency manual operations

Automation owns routine desired state. Emergency manual change is permitted only when the incident procedure requires it, with evidence preserved and a follow-up reconciliation/drift review. “Humans can also edit anything whenever needed” creates two competing sources of truth and makes rollback/audit ambiguous.

6. Operating cadence

These are example operating cadences for the capstone. Real organizations align them to business impact, change frequency, regulation, and platform scale.

7. Final evidence manifest

{
  "architecture": "approved",
  "desiredStateReconciliation": "idempotence-proved",
  "leastPrivilege": "positive-and-negative-tests-passed",
  "multiFormatPublication": ["maven2", "npm", "raw-evidence"],
  "promotion": "same-bytes-same-sha256",
  "policy": "free-fixture-passed; licensed-extension-optional",
  "cleanup": "preview-before-delete",
  "observability": "client-to-db-blob-upstream-correlation-proved",
  "backupRestore": "isolated-restore-passed",
  "migrationUpgrade": "gates-and-rehearsal-documented",
  "ha": "simulation-complete; Pro-required-for-live-HA",
  "rpoMinutesObservedFixture": 22,
  "rtoMinutesObservedFixture": 46,
  "handoff": "runbooks-and-owners-assigned"
}

8. Final automated readiness gate

checks={
 "architecture": True,
 "idempotent_reconcile": True,
 "least_privilege_negative_tests": True,
 "multi_format_publish": True,
 "immutable_identity": True,
 "policy_boundary_labeled": True,
 "cleanup_preview": True,
 "observability_baseline": True,
 "backup_restore_proven": True,
 "migration_upgrade_rehearsal": True,
 "ha_not_confused_with_backup": True,
 "rpo_met": 22 <= 30,
 "rto_met": 46 <= 60,
 "runbooks_owned": True,
 "no_real_secrets": True,
}
failed=[name for name,ok in checks.items() if not ok]
print("PRODUCTION-READINESS-LAB: PASS" if not failed else "NO-GO")
print("failed:",failed)
assert not failed

9. Paid-capability handoff

10. Course-wide operating model

The 30 chapters form one progression:

1. Identity of artifacts: components/assets, coordinates, checksums/digests, package-format metadata.
2. Repository topology: hosted/proxy/group and cache/routing behavior.
3. Persistent state: database, blob stores, storage/capacity.
4. Package ecosystems: Maven, npm, Docker/OCI, Python, NuGet, OS/generic and emerging formats.
5. Security: selectors, roles, realms, external identity, TLS/network exposure.
6. Operations: cleanup, tasks, REST automation, webhooks/CI, promotion.
7. Supply chain: IQ/Firewall boundaries, SBOM/provenance/vulnerability governance.
8. Lifecycle: Docker operations, backup/restore, migration, upgrades, HA.
9. Evidence: logging, metrics, support ZIPs, performance/capacity diagnostics.
10. Capstone: these controls combined into an owned, testable, recoverable delivery platform.

11. What the platform guarantees—and what it does not

A well-operated artifact platform can provide controlled publication/consumption paths, durable artifact storage, access control, caching, retention, evidence, automation, and tested recovery. It does not automatically prove that every package is safe, that every build is reproducible, that every signer is trustworthy, or that every direct-public path is closed. Those guarantees require complementary build, identity, network, provenance, vulnerability, and organizational controls.

12. Final cleanup of the mandatory lab

Export/retain the redacted evidence packet, then list every disposable resource. Delete only resources whose names begin with capstone-lab- through supported Nexus APIs/UI, and remove temporary Maven/npm/client homes. Do not delete database rows or blob files. Do not delete the only recovery evidence before you have verified that the lab no longer needs it.

13. Final production-readiness review

14. Course completion

You have moved from “What is an artifact repository?” to a complete operating model that can be designed, implemented, secured, automated, monitored, changed, migrated, upgraded, recovered, and handed off. The enduring skill is not memorizing the 3.95 UI. It is being able to identify state, trust boundaries, version/edition constraints, evidence, failure modes, and the least destructive supported path as Nexus Repository evolves.

Knowledge check

Summary and next step

The capstone is complete: architecture, desired state, multi-format publication, least privilege, build-once identity, policy boundaries, cleanup, observability, tested recovery, migration/upgrade gates, HA semantics, failure drills, ownership, and runbooks are tied into one production operating model.

This is the final lesson of the Nexus Repository course. Return to the Course curriculum to review any chapter or repeat the capstone against a fresh disposable environment when future Nexus releases change the supported operational boundaries.

Official references and version notes

• Sonatype: Nexus Repository documentation — current self-hosted product entry point and supported-format documentation.
• Sonatype: 2026 self-hosted release notes — release-specific changes and known-issue/upgrade guidance.
• Sonatype: Self-Hosted Feature Matrix — Community versus Pro capability boundary.
• Sonatype: System Requirements — Java 21, H2 workload limits, PostgreSQL guidance, sizing, file handles, and deployment constraints.
• Sonatype: Repository Types — hosted, proxy, and group responsibilities.
• Sonatype: Content Selectors — fine-grained content authorization concepts.
• Sonatype: Cleanup Policies — retention criteria, preview/evaluation, deletion semantics, and blob reclamation boundary.
• Sonatype: REST and Integration API — documented REST/OpenAPI automation boundary.
• Sonatype: Webhooks — repository/global events and delivery semantics.
• Sonatype: Staging — current Pro-only staged component movement/promotion capability.
• Sonatype: Repository Firewall — separately licensed IQ-powered policy integration and supported Nexus editions.
• Sonatype: Prepare a Backup — coordinated database/blob backups and node-ID preservation.
• Sonatype: Database migration — current migration tooling and compatibility gates.
• Sonatype: Instance Migrator — current source/target migration workflow and constraints.
• Sonatype: Upgrade Paths — version thresholds and mandatory crossed-version procedures.
• Sonatype: Rolling Upgrades in HA — Pro/HA rolling-upgrade behavior and mixed-mode constraints.
• Sonatype: HA system requirements — Pro-only active-node topology, shared PostgreSQL/blob state, and failure-domain requirements.
• Sonatype: Logging — application/request/outbound/audit/JVM evidence.
• Sonatype: Prometheus — current metrics endpoint and privilege boundary.
• Sonatype: Support Features — support ZIP generation and evidence handling.