Alternative Container Registries jenseits von Docker Hub

1. Warum Docker Hub allein nicht mehr für jedes Team reicht

Docker Hub war über Jahre die faktische Standardregistry, weil sie einfach zu nutzen war und die meisten offiziellen Basis-Images dort lagen. Seit der Einführung strikter Rate Limits für anonyme und unauthentifizierte Pulls stoßen viele CI-Pipelines jedoch regelmäßig an Grenzen, besonders wenn mehrere parallele Jobs auf demselben Runner-Pool dieselbe IP-Adresse teilen. Alternative Container Registries lösen dieses Problem, indem sie entweder eigene, höhere Limits anbieten oder komplett anders abrechnen.

Neben Rate Limits treiben auch Compliance-Anforderungen Teams zu alternativen Container Registries. Unternehmen mit strengen Datenresidenz-Vorgaben wollen Images oft nicht bei einem externen SaaS-Anbieter, sondern in der eigenen Cloud-Region oder komplett selbst gehostet vorhalten. Zusätzlich spielt die Integration in bestehende Werkzeuge eine Rolle: Eine Registry, die direkt neben dem Quellcode-Repository liegt, vereinfacht Zugriffsrechte und Audit-Trails erheblich gegenüber einer komplett separaten, extern gehosteten Lösung.

Die Wahl zwischen den verschiedenen alternativen Container Registries hängt stark vom bestehenden Toolchain-Kontext ab. Ein Team, das bereits GitLab für Quellcode und CI nutzt, profitiert typischerweise am meisten von der integrierten GitLab Registry, während ein Team mit AWS-lastiger Infrastruktur eher zu Amazon ECR tendiert. Die folgenden Abschnitte gehen auf die konkreten Eigenschaften der wichtigsten Alternativen ein.

2. GitLab Container Registry: Registry direkt neben dem Code

Die GitLab Container Registry ist für Teams, die GitLab bereits für Quellcode-Verwaltung und CI/CD nutzen, oft die naheliegendste unter den alternativen Container Registries. Jedes Projekt bekommt automatisch einen eigenen Registry-Namespace, Zugriffsrechte folgen direkt den Projekt- und Gruppenberechtigungen, und CI-Jobs authentifizieren sich ohne zusätzliche Secrets über die eingebaute CI_REGISTRY_PASSWORD-Variable.

Ein praktischer Vorteil dieser alternativen Container Registry ist die enge Kopplung an Aufbewahrungsrichtlinien: GitLab erlaubt es, pro Projekt automatisch alte, ungenutzte Image-Tags nach konfigurierbaren Regeln zu löschen, etwa alle Tags älter als 90 Tage außer den letzten fünf. Das verhindert unkontrolliertes Wachstum der Registry, ohne dass ein separates Cleanup-Skript gepflegt werden muss.

# Authenticate and push to the GitLab Container Registry from CI
echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"

docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

# Registry cleanup policy is configured per project (Settings > Packages & Registries)
# Example: keep the 5 most recent tags, remove anything older than 90 days

3. GitHub Container Registry: enge Integration mit Actions

Die GitHub Container Registry, kurz GHCR, verfolgt einen ähnlichen Ansatz wie GitLab, ist aber auf das GitHub-Ökosystem zugeschnitten. Als alternative Container Registry punktet GHCR vor allem durch die nahtlose Integration in GitHub Actions über das eingebaute GITHUB_TOKEN, das ohne separate Secrets-Verwaltung Push- und Pull-Rechte für das jeweilige Repository bereitstellt. Images lassen sich zudem direkt mit einem GitHub-Repository verknüpfen, sodass Nutzer vom Quellcode aus direkt zu den verfügbaren Container-Versionen navigieren können.

Für Open-Source-Projekte ist GHCR als alternative Container Registry besonders attraktiv, weil öffentliche Images kostenlos und ohne Rate Limits für authentifizierte Pulls bereitgestellt werden, ein deutlicher Unterschied zu den strikten anonymen Limits von Docker Hub. Private Repositories zahlen nach Speicherplatz und Datentransfer, was für kleinere Teams meist günstiger ist als eine dedizierte Docker-Hub-Pro-Lizenz.

# .github/workflows/build.yml -- push to GHCR using the built-in token
name: Build and push
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
      - name: Build and push
        run: |
          docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
          docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

4. Amazon ECR: Registry in der eigenen Cloud-Infrastruktur

Amazon Elastic Container Registry ist die naheliegende Wahl unter den alternativen Container Registries, wenn die Anwendung ohnehin in AWS läuft, etwa auf ECS, EKS oder Lambda. Der entscheidende Vorteil: Datentransfer zwischen ECR und anderen AWS-Diensten in derselben Region ist kostenlos und deutlich schneller als ein Pull von einer externen Registry über das öffentliche Internet, was besonders bei häufigen Deployments spürbar wird.

Sicherheitsrelevant ist bei dieser alternativen Container Registry die tiefe Integration mit IAM: Zugriffsrechte auf Repository-Ebene lassen sich präzise über IAM-Policies steuern, ohne separate Registry-Zugangsdaten zu verwalten. ECR bietet zudem integriertes Vulnerability Scanning auf Basis von Amazon Inspector, das bei jedem Push automatisch nach bekannten Schwachstellen sucht, ohne ein externes Scanning-Tool in die Pipeline einbinden zu müssen.

# Authenticate to Amazon ECR and push an image
aws ecr get-login-password --region eu-central-1 \
  | docker login --username AWS --password-stdin 123456789012.dkr.ecr.eu-central-1.amazonaws.com

docker build -t myapp .
docker tag myapp:latest 123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.4.2
docker push 123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.4.2

# Vulnerability scan results are available via the AWS CLI
aws ecr describe-image-scan-findings --repository-name myapp --image-id imageTag=1.4.2

5. Harbor: selbst gehostet mit Enterprise-Funktionen

Harbor ist ein CNCF-Graduated-Projekt und die verbreitetste Wahl unter den alternativen Container Registries, wenn ein Team eine vollständig selbst gehostete Lösung mit Enterprise-Funktionen benötigt, etwa aus Datenresidenz- oder Air-Gap-Gründen. Harbor bringt eingebautes Vulnerability Scanning über Trivy, rollenbasierte Zugriffskontrolle, Image-Signierung mit Notary und ein Replikations-Feature mit, das Images automatisch zwischen mehreren Harbor-Instanzen oder in externe Registries synchronisiert.

Der Betrieb von Harbor als alternative Container Registry erfordert allerdings eigene Infrastruktur-Verantwortung: Updates, Backups und Skalierung liegen vollständig beim eigenen Team, im Gegensatz zu den vollständig verwalteten Angeboten von GitLab, GitHub oder AWS. Für Organisationen mit strengen Compliance-Vorgaben, etwa im Finanz- oder Gesundheitssektor, überwiegt dieser Mehraufwand aber oft die Vorteile einer verwalteten Lösung, weil Harbor vollständige Kontrolle über Speicherort und Zugriff bietet.

6. Pull-Through-Mirroring gegen Rate Limits

Nicht jedes Team muss vollständig von Docker Hub wegziehen, um alternative Container Registries sinnvoll zu nutzen. Pull-Through-Caching-Mirrors lösen das Rate-Limit-Problem, ohne bestehende Image-Referenzen im Code zu ändern: Ein Mirror wie der von Amazon ECR oder eine selbst gehostete Harbor-Instanz mit Proxy-Cache-Funktion fängt Pulls für Docker-Hub-Images ab, zwischenspeichert sie und liefert nachfolgende Anfragen aus dem eigenen Cache, ohne erneut gegen die Docker-Hub-Limits zu laufen.

Diese Mirror-Strategie unter den alternativen Container Registries eignet sich besonders für Teams mit vielen CI-Läufen, die dieselben Basis-Images wie node, php oder mysql ständig neu ziehen. Der erste Pull eines Images läuft weiterhin gegen Docker Hub, jeder folgende Pull innerhalb der Cache-Gültigkeit kommt aus dem eigenen, unlimitierten Mirror.

# Harbor pull-through cache configuration (project as a proxy cache project)
# In Harbor UI: Projects > New Project > Proxy Cache > docker.io
# Then reference images through the Harbor proxy instead of Docker Hub directly:

# BEFORE: direct pull, subject to Docker Hub rate limits
# FROM node:20-alpine

# AFTER: pull through Harbor's cached proxy project
# FROM harbor.example.com/dockerhub-proxy/library/node:20-alpine

7. Migration weg von Docker Hub in der Praxis

Der Umstieg auf alternative Container Registries muss nicht als einmaliger Big-Bang-Schritt erfolgen. Ein bewährtes Vorgehen beginnt mit dem Kopieren aller aktiv genutzten Images in die neue Registry, während Docker Hub parallel als Fallback erreichbar bleibt. Werkzeuge wie crane copy oder skopeo copy übertragen Images direkt zwischen Registries, ohne lokalen Zwischenspeicher, und lassen sich in ein einmaliges Migrationsskript packen.

Nach dem initialen Kopieren werden CI-Konfigurationen und Dockerfiles schrittweise auf die neue alternative Container Registry umgestellt, Projekt für Projekt statt in einem einzigen riskanten Schritt. Erst wenn alle produktiven Referenzen umgestellt sind und ein Beobachtungszeitraum von einigen Wochen ohne Probleme verstrichen ist, wird die alte Docker-Hub-Referenz endgültig entfernt.

#!/usr/bin/env bash
# migrate-to-alternative-registry.sh -- copy images from Docker Hub to GHCR
set -euo pipefail

IMAGES=("myorg/myapp:1.4.0" "myorg/myapp:1.4.1" "myorg/myapp:1.4.2")
TARGET="ghcr.io/myorg"

for image in "${IMAGES[@]}"; do
  echo "[migrate] Copying docker.io/${image} -> ${TARGET}/${image#*/}"
  crane copy "docker.io/${image}" "${TARGET}/${image#*/}"
done

echo "[migrate] Done. Update Dockerfiles and CI configs to reference ${TARGET}."

8. Typische Fehler bei der Registry-Auswahl

Der häufigste Fehler bei der Auswahl alternativer Container Registries ist, eine Migration ausschließlich aus Kostengründen durchzuführen, ohne die operative Verantwortung zu berücksichtigen. Ein Team, das von einer vollständig verwalteten Docker-Hub-Lösung zu einer selbst gehosteten Harbor-Instanz wechselt, übernimmt damit auch Betriebsaufwand für Updates, Backups und Verfügbarkeit, der zuvor komplett extern lag.

# WRONG: hardcoding a single registry host everywhere, no abstraction
FROM docker.io/library/node:20-alpine

# RIGHT: parametrize the registry host, migration becomes a one-line change
ARG REGISTRY_HOST=docker.io/library
FROM ${REGISTRY_HOST}/node:20-alpine

Ein zweiter verbreiteter Fehler ist, Registry-Referenzen fest im Code zu verankern, statt sie parametrisierbar zu halten. Wenn jedes Dockerfile und jede CI-Konfiguration die Registry-URL fest kodiert, wird ein späterer Wechsel zwischen alternativen Container Registries zu einer aufwändigen Suchen-und-Ersetzen-Aktion über den gesamten Codebestand, statt einer einzigen Konfigurationsänderung.

9. Alternative Container Registries im direkten Vergleich

Die folgende Tabelle vergleicht die wichtigsten alternativen Container Registries anhand praxisrelevanter Kriterien.

Die Wahl unter den alternativen Container Registries ist selten eine reine Feature-Entscheidung, sondern hängt stark davon ab, welche Plattform ein Team bereits für Quellcode und CI nutzt. Ein pragmatischer Zwischenschritt für viele Teams ist ein Pull-Through-Mirror, der die Rate-Limit-Probleme sofort löst, ohne eine vollständige Migration zu erzwingen.

10. Zusammenfassung

Alternative Container Registries lösen konkrete Probleme, die Docker Hub allein für viele Teams nicht mehr abdeckt: Rate Limits bei hoher CI-Last, Compliance-Anforderungen an Datenresidenz, und der Wunsch nach engerer Integration in bestehende Quellcode- und CI-Plattformen. GitLab Registry und GitHub Container Registry bieten sich für Teams an, die die jeweilige Plattform bereits nutzen, Amazon ECR für AWS-lastige Infrastrukturen, und Harbor für Organisationen mit strengen Compliance-Anforderungen und eigener Betriebskapazität.

Für Teams, die keinen vollständigen Wechsel wollen, ist ein Pull-Through-Mirror die pragmatischste Lösung: Er entschärft das Rate-Limit-Problem, ohne bestehende Image-Referenzen und Prozesse grundlegend zu ändern. Wichtig bei jeder Migration ist, Registry-Referenzen von Anfang an parametrisierbar zu halten, damit ein späterer Wechsel keine aufwändige Suchen-und-Ersetzen-Aktion über den gesamten Codebestand erfordert.

11. FAQ: Alternative Container Registries jenseits von Docker Hub