Harbor vs. Nexus Repository: Die richtige Artefakt-Registry für dein DevOps-Setup

Wer Kubernetes, Docker-Pipelines oder mehrsprachige Enterprise-Projekte betreibt, braucht früher oder später eine Artefakt-Registry — einen zentralen Speicher für Container-Images, Helm-Charts, Maven-Artifacts, npm-Pakete und mehr. Zwei der bekanntesten Lösungen im Self-Hosting-Bereich sind Harbor von VMware (heute CNCF-graduiert) und Nexus Repository von Sonatype. Beide sind Open Source (Community-Edition), lösen aber unterschiedliche Probleme. Dieser Artikel zeigt, welche Lösung für dein Setup besser passt.

Was ist Harbor?

Harbor ist eine cloud-native, OCI-konforme Container-Registry, die 2016 von VMware als Open-Source-Projekt gestartet wurde. 2018 spendete VMware Harbor der Cloud Native Computing Foundation (CNCF), wo es 2020 den Graduated-Status erreichte — ein Qualitätsmerkmal für Enterprise-Readiness im Kubernetes-Ökosystem.

Harbor ist spezialisiert auf Container-Artefakte: Docker-Images, OCI-Artefakte und Helm-Charts. Es bringt ein vollständiges Feature-Set für sichere Container-Workflows mit:

  • RBAC (rollenbasierte Zugriffskontrolle) auf Projekt-Ebene
  • Vulnerability-Scanning via Trivy (integriert) oder Clair
  • Image-Signing via Cosign / Notary v2
  • Replication zwischen mehreren Harbor-Instanzen oder externen Registries (Docker Hub, ECR, GCR)
  • Quota-Management per Projekt
  • Content Trust und Image-Signaturverifizierung
  • Webhooks für CI/CD-Integrationen
  • Proxy Cache für öffentliche Registries (schützt vor Docker Hub Rate Limits)

Harbor lässt sich sowohl über Docker Compose als auch als Kubernetes-Helm-Chart deployen und ist für container-zentrierte DevOps-Teams optimiert.

Was ist Nexus Repository?

Nexus Repository Manager (kurz: Nexus) von Sonatype ist ein universeller Artefakt-Manager, der seit 2008 Enterprise-Teams in mehrsprachigen Umgebungen unterstützt. Die Open-Source-Version heißt Nexus Repository OSS; die Pro-Version enthält erweiterte Features wie High Availability und fortgeschrittenes Staging.

Nexus unterstützt über 20 Paketformate, darunter:

  • Maven/Gradle (Java-Ökosystem)
  • npm, Yarn (JavaScript)
  • PyPI (Python)
  • Docker/OCI (Container-Images)
  • Helm (Kubernetes)
  • apt, yum/RPM (Linux-Pakete)
  • NuGet (.NET)
  • RubyGems, Go modules, Conda, R

Nexus ist damit deutlich breiter aufgestellt als Harbor, kommt aber mit höherem Ressourcenverbrauch (JVM-basiert) und einer steileren Lernkurve.

Feature-Vergleich: Harbor vs. Nexus Repository

Feature Harbor Nexus Repository OSS
Primärfokus Container-Images, OCI Multi-Format (20+ Typen)
Docker/OCI ✅ Nativ ✅ Unterstützt
Helm-Charts ✅ Nativ ✅ Unterstützt
Maven/npm/PyPI ❌ Nicht unterstützt ✅ Kernstärke
Vulnerability Scanning ✅ Trivy integriert ⚠️ Nur Pro (IQ Server)
Image Signing ✅ Cosign/Notary ❌ Nicht nativ
RBAC ✅ Granular ✅ Vorhanden
Proxy/Pull-through Cache ✅ ✅
Replikation ✅ Multi-Registry ⚠️ Eingeschränkt in OSS
CNCF-Projekt ✅ Graduated ❌
Technologie-Stack Go + Vue.js Java (JVM)
RAM-Bedarf ~2 GB ~4–8 GB
Lizenz Apache 2.0 Apache 2.0 (OSS)

Installation & Betrieb

Harbor installieren

Harbor bietet zwei Installationswege:

1. Docker Compose (empfohlen für Single-Node):

# Harbor Installer herunterladen
wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-online-installer-v2.11.0.tgz
tar xzvf harbor-online-installer-v2.11.0.tgz
cd harbor

# Konfiguration anpassen
cp harbor.yml.tmpl harbor.yml
# hostname, https-Zertifikat, admin-Passwort setzen
nano harbor.yml

# Installation starten
./install.sh --with-trivy

2. Kubernetes Helm Chart:

helm repo add harbor https://helm.goharbor.io
helm install harbor harbor/harbor \
  --namespace harbor --create-namespace \
  --set expose.type=ingress \
  --set expose.ingress.hosts.core=harbor.example.com \
  --set externalURL=https://harbor.example.com

Harbor läuft mit einem Stack aus mehreren Containern (Registry, Core, Portal, Job Service, Database, Redis, Trivy). Der Resource-Footprint ist moderat (~2 GB RAM im Idle).

Nexus Repository installieren

# Via Docker (einfachste Methode)
docker run -d -p 8081:8081 \
  --name nexus \
  -v nexus-data:/nexus-data \
  sonatype/nexus3:latest

Nexus startet langsam (60–120 Sekunden JVM-Warmup) und benötigt deutlich mehr RAM. Empfohlen werden mindestens 4 GB, für produktive Setups eher 8 GB. Das Admin-Passwort findet sich beim ersten Start unter /nexus-data/admin.password.

Sicherheit: Vulnerability Scanning und Image Signing

Harbor bietet hier einen klaren Vorteil für Container-Workloads:

  • Trivy-Integration: Jedes gepushte Image wird automatisch auf bekannte CVEs gescannt. Im Dashboard sieht man direkt, welche Images kritische Schwachstellen haben.
  • Image Signing mit Cosign: Harbor unterstützt die OCI-konforme Signaturverifizierung — Container-Images lassen sich kryptografisch signieren und die Signatur beim Pull verifizieren.
  • Content Trust: Unsigned Images können pro Projekt blockiert werden, was Software-Supply-Chain-Angriffe erschwert.

Nexus OSS bietet kein integriertes Vulnerability-Scanning für Container-Images. Sonatype vertreibt dafür Nexus IQ Server als separate (kostenpflichtige) Lösung, die sich mit Nexus Repository integrieren lässt.

Für Maven/npm-Pakete gibt es eigene Scanning-Tools wie OWASP Dependency Check oder Snyk, die in CI/CD-Pipelines integriert werden können — unabhängig vom verwendeten Repository Manager.

Proxy-Cache und Rate-Limit-Schutz

Beide Tools unterstützen Proxy-Repositories (Pull-through Cache): Anfragen an Docker Hub, npm Registry oder Maven Central werden über die eigene Instanz gecacht, was:

  • Docker Hub Rate Limits umgeht (200 Pulls/6h für anonyme Nutzer)
  • Ausfallsicherheit bei Upstream-Problemen bietet
  • Netzwerk-Traffic und Build-Zeiten reduziert

Harbors Proxy-Cache-Feature ist besonders für Container-Heavy-Setups nützlich und einfach per UI konfigurierbar. Nexus glänzt als Proxy für Maven Central und npm Registry in Enterprise-Java-Umgebungen.

Wann Harbor wählen?

Harbor ist die richtige Wahl, wenn:

  • Container-First-Umgebung: Dein Stack dreht sich primär um Docker, Kubernetes und Helm-Charts
  • Sicherheit ist kritisch: Du brauchst integrierten Vulnerability-Scan (Trivy) ohne zusätzliche Tools
  • CNCF-Ökosystem: Du willst eine CNCF-graduierte Lösung mit breiter Community-Unterstützung
  • Image Signing: Software-Supply-Chain-Sicherheit via Cosign ist ein Muss
  • Leichtgewichtigere Alternative: Harbor braucht weniger RAM als Nexus (2 GB vs. 4–8 GB)

Typische Harbor-Nutzer: DevOps-Teams, die Kubernetes betreiben, auf Sicherheits-Scanning angewiesen sind und eine dedizierte Container-Registry brauchen — ohne den Overhead eines universellen Artefakt-Managers.

Wann Nexus Repository wählen?

Nexus ist die bessere Wahl, wenn:

  • Multi-Language-Umgebung: Dein Team entwickelt in Java, JavaScript, Python und mehr gleichzeitig
  • Maven/Gradle ist Kern: Java-Enterprise-Projekte brauchen eine Maven-Registry — das ist Nexus' ureigene Stärke
  • Legacy-Enterprise: Nexus ist in vielen Enterprise-Teams seit Jahren etabliert und tief integriert
  • One-Stop-Shop: Du willst alle Artefakte (Container, Pakete, Binaries) in einem einzigen System verwalten
  • apt/yum-Repos: Für Linux-Paketverteilung in der Infrastruktur ist Nexus deutlich besser aufgestellt

Typische Nexus-Nutzer: Enterprise-Teams mit heterogenem Tech-Stack, Java-lastige Umgebungen, Firmen mit langjähriger Nexus-Nutzung.

Migration: Zwischen den Tools wechseln

Wer von Nexus zu Harbor wechselt (oder umgekehrt), muss Container-Images mit docker tag und docker push migrieren. Ein Skript wie das folgende übernimmt das automatisch:

#!/bin/bash
SOURCE="nexus.example.com:8082"
TARGET="harbor.example.com"
PROJECT="myproject"

for image in $(docker images --format "{{.Repository}}:{{.Tag}}" | grep $SOURCE); do
  new_image="${TARGET}/${PROJECT}/${image#$SOURCE/}"
  docker tag $image $new_image
  docker push $new_image
  echo "Migriert: $image → $new_image"
done

Nexus-Repositories für Maven, npm oder PyPI lassen sich nicht direkt nach Harbor migrieren — Harbor unterstützt diese Formate schlicht nicht. Wer von Nexus zu Harbor wechselt, benötigt für nicht-Container-Artefakte eine alternative Lösung (Gitea Packages, Verdaccio für npm, etc.).

Fazit: Harbor für Container, Nexus für Multi-Format

Harbor ist die klare Wahl für Teams, die primär mit Kubernetes und Containern arbeiten. Die integrierten Security-Features (Trivy-Scanning, Cosign-Signing) und der CNCF-Graduated-Status machen Harbor zur Enterprise-tauglichen Container-Registry par excellence.

Nexus Repository ist besser für Enterprise-Umgebungen, die multiple Sprachen und Build-Systeme vereinen müssen. Wer neben Container-Images auch Maven-Artifacts, npm-Pakete und PyPI-Module in einem System verwalten will, kommt an Nexus kaum vorbei.

Für reine Self-Hosting-Setups auf Kubernetes ist Harbor die schlankere, modernere Lösung. Für polyglotte Enterprise-Teams mit Java-Kernkompetenz bleibt Nexus der bewährte Standard — auch wenn der Ressourcenhunger erheblich ist.

Weiterführende Artikel

Verwandte Technologien im Techradar