Docker Hub EU Alternative 2026: GDPR, CLOUD Act, and the Container Registry Compliance Gap

Post #785 in the sota.io EU Compliance Series

Every docker pull is a data transfer. When you build and ship container images via Docker Hub, you hand Docker Inc. — a US company — control over a critical node in your software supply chain. Under the CLOUD Act, every image layer, pull log, and user analytics record can be compelled from Docker without your knowledge. Under GDPR, the implications run deeper than most teams realise.

This is the complete GDPR analysis of Docker Hub and the best EU-sovereign container registry alternatives for 2026.

Why Container Registries Are a GDPR Problem

Container registries look like a pure infrastructure concern — just bytes stored and served. But they sit at the intersection of three compliance domains:

1. Data processing: Images may contain PII baked into layers.
2. Supply-chain security: NIS2 Art.21 explicitly requires managing ICT supply-chain risks.
3. Jurisdictional control: A US-based registry means a US court can compel your build artefacts, pull logs, and usage analytics.

Most compliance reviews stop at databases and APIs. Registries are the blind spot.

Docker Hub and the CLOUD Act

Docker Inc. is incorporated in San Francisco, California. That makes every Docker Hub service subject to the Clarifying Lawful Overseas Use of Data (CLOUD) Act (18 U.S.C. § 2523).

The CLOUD Act allows US law enforcement to demand data from US-based providers regardless of where that data is physically stored. Docker's EU-region infrastructure does not change the jurisdictional exposure — the company is US-based, and that is what matters.

What can be compelled under a CLOUD Act order targeting Docker Hub:

• Image manifests and layer blobs — including any PII accidentally baked into layers
• Pull statistics and access logs — who in your organisation pulls what images and when
• User account data — team members, authentication tokens, linked email addresses
• Push timestamps and CI/CD metadata — revealing your deployment patterns and release cadence

None of this requires a warrant in the traditional sense. A National Security Letter can compel disclosure with a gag order — you may never know it happened.

GDPR Art.28 — Docker Hub as a Data Processor

When you push images that contain personal data — even indirectly through configuration — Docker Hub becomes a data processor under Art.28 GDPR. This requires:

• A signed Data Processing Agreement (DPA) with Docker Inc.
• Explicit documentation of the categories of personal data processed
• Assurance that Docker Inc. will only process data on your documented instructions

Docker offers a DPA for paid plans. But the DPA cannot override the CLOUD Act. Standard Contractual Clauses (SCCs) under Art.46 GDPR provide a contractual transfer mechanism, but the European Data Protection Board's post-Schrems II guidance makes clear: where US surveillance law creates a fundamental incompatibility with EU fundamental rights, SCCs cannot cure the gap.

The Docker Hub DPA does not solve your CLOUD Act exposure — it just creates the paper trail for your Art.30 records.

Art.44 — Every docker pull Is a Cross-Border Transfer

Docker Hub's default CDN infrastructure delivers image layers from US-based edge nodes. When a developer or CI runner executes docker pull company/app:prod, the layer blobs may be served from US jurisdiction — constituting an Art.44 cross-border data transfer.

The key question: do your images contain personal data?

Under GDPR Art.4(1), personal data is "any information relating to an identified or identifiable natural person." Image layers regularly contain:

• Hardcoded configuration referencing user identifiers, email addresses, or employee IDs
• Build-time secrets injected via ARG or ENV that weren't properly redacted
• SSL certificates containing organisational identity data
• Embedded test fixtures with real user data (a common developer shortcut)
• Application logs baked into debug images

If any of these exist in a layer that transits US CDN infrastructure, that is an Art.44 transfer without adequate safeguards — unless you have valid SCCs in place with Docker and have conducted a Transfer Impact Assessment (TIA) per the EDPB's Recommendations 01/2020.

Most teams have done neither.

Art.17 Right to Erasure — The Image Layer Problem

Docker's content-addressable storage is architecturally at odds with GDPR Art.17. Here is why.

Each image layer is identified by its SHA-256 digest. Layers are immutable and shared: if two images include the same apt-get install layer, they reference the same blob. When you delete an image tag or even a repository, Docker Hub does not immediately delete the underlying layer blobs — because those blobs may still be referenced by other images.

This creates an Art.17 erasure gap:

1. You push an image containing PII (accidentally or intentionally).
2. Other images are built on top of it — the PII layer is now referenced by multiple manifests.
3. You receive a data subject erasure request.
4. You cannot delete the PII layer without potentially breaking every image that references it.
5. Even if you delete your repository, Docker Hub's garbage collection runs on its own schedule.
6. Caches at Docker Hub edge nodes, in third-party CIs, and on developer laptops retain the layer indefinitely.

The only path to true erasure is to rebuild the entire image chain from the PII layer upward, push new digests, and migrate all downstream consumers. In practice this is operationally infeasible for large image hierarchies.

EU-sovereign registries running under your control give you deterministic garbage collection — you can run registry garbage-collect --delete-untagged on your own schedule and verify the blobs are gone.

NIS2 Art.21 — The Supply-Chain Security Obligation

The EU's NIS2 Directive (Directive 2022/2555), applicable from October 2024, introduces an explicit supply-chain security obligation for essential and important entities. Art.21(2)(d) requires:

"supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers"

A container registry is a first-class supply-chain node. Every service you deploy ultimately depends on the integrity of the registry serving your base images. If Docker Hub is:

• Compromised by a state-sponsored actor (as has happened to major US tech platforms)
• Compelled to inject a backdoored layer under a classified CLOUD Act order
• Experiencing an outage (Docker Hub has had multiple production outages affecting enterprise teams)

...then your entire production stack is affected.

NIS2 Art.21 compliance requires you to conduct risk assessments of your ICT supply chain. A DPIA or ICT risk assessment that does not address registry provenance is incomplete. Regulators in DE (BSI), NL (NCSC-NL), and FR (ANSSI) have all published guidance identifying container registry integrity as a supply-chain risk.

Running your own EU-sovereign registry eliminates this vector and simplifies your NIS2 Art.21 documentation.

Art.25 — Privacy by Design and Image Lineage

Art.25 GDPR requires privacy by design and by default: "the controller shall implement appropriate technical and organisational measures...designed to implement data-protection principles." For container workflows, this means:

• Minimisation: base images should contain only the software needed. Docker Hub's official images are often over-provisioned with tools that expand the PII surface.
• Layer transparency: you need to know what every layer contains. Docker Hub does not provide a built-in SBOM (Software Bill of Materials) for images.
• Access control: who can pull production images should be logged and audited. Docker Hub's free tier provides no pull-level audit log.

Harbor, the leading open-source registry, includes built-in SBOM generation via Cosign and Syft integrations. Your Art.25 documentation can reference specific SBOM artefacts stored alongside the image — a defensible, auditable trail of what personal data surfaces existed at each release.

Docker Hub Pull Rate Limits — A Compliance Side Effect

Docker Hub's pull rate limits (100 pulls/6h for unauthenticated, 200/6h for free accounts) forced many teams to authenticate their CI pipelines with Docker Hub credentials. This authentication:

• Creates an account-level audit trail in Docker's US infrastructure
• Links your CI/CD IP addresses and pull patterns to your Docker Hub account
• Exposes build metadata (image names, tags, timestamps) to Docker Inc.

Under Art.30 GDPR you must maintain records of processing activities. If your CI authentication creates a data flow to Docker Inc., that flow must be documented and covered by your DPA and Art.46 transfer mechanism. Most teams have not documented this flow.

The EU-Sovereign Container Registry Alternatives

Harbor (Recommended for Enterprises)

Harbor (https://goharbor.io) is the CNCF-graduated open-source container registry. It supports OCI artefacts, Helm charts, and integrates natively with Cosign for image signing.

Key capabilities:

• Built-in SBOM generation and vulnerability scanning (Trivy)
• Role-based access control with full audit logging
• Replication policies for geo-redundant EU deployments
• Proxied pull-through cache (shields Docker Hub dependency while keeping pull logs local)
• OIDC/SAML integration for enterprise SSO

Deploy on Hetzner Cloud (DE/FI — choose for EU jurisdiction), IONOS, or OVHcloud:

# Helm install on a Hetzner Kubernetes cluster (Frankfurt region)
helm repo add harbor https://helm.goharbor.io
helm install harbor harbor/harbor \
  --set expose.type=ingress \
  --set expose.ingress.hosts.core=registry.example.eu \
  --set externalURL=https://registry.example.eu \
  --set persistence.persistentVolumeClaim.registry.size=100Gi \
  --namespace harbor --create-namespace

All data remains under German jurisdiction. Harbor's Apache 2.0 licence has no CLA requiring IP assignment to a US entity.

Forgejo / Gitea Container Registry

Forgejo (https://forgejo.org) is the community-owned fork of Gitea, governed by the Codeberg e.V. association (Berlin, DE). Its built-in container registry supports OCI distribution spec v1.1.

Why Forgejo for GDPR compliance:

• Codeberg e.V. is a German non-profit — no US parent company, no CLOUD Act exposure
• Self-hosted option: deploy on any EU infrastructure
• Forgejo Actions (CI/CD) integrated — complete build and publish pipeline within EU jurisdiction
• Container registry pulls are logged in your own database

# Push to a self-hosted Forgejo registry
docker login git.example.eu
docker tag myapp:latest git.example.eu/myorg/myapp:latest
docker push git.example.eu/myorg/myapp:latest

GitLab CE Container Registry

GitLab Community Edition includes a full container registry (distribution/distribution upstream). Self-hosted GitLab on Hetzner or Scaleway gives you:

• Pipeline-integrated builds and registry in one jurisdiction
• Project-level and group-level access control
• Log retention configurable to your GDPR retention schedule

Zot Registry

Zot (https://zotregistry.dev) is a CNCF sandbox project — a minimal, OCI-native registry with zero dependency on Docker's distribution codebase. Designed for air-gapped and security-sensitive deployments.

Good fit for: regulated industries, financial services, healthcare — anywhere an audit trail of every manifest operation is required for compliance.

Migration Guide: Docker Hub → EU Registry

Phase 1: Audit existing images for PII exposure (1-2 days)

# Inspect layer contents with dive
docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  wagoodman/dive:latest myapp:latest

# Scan layers for common PII patterns
docker history --no-trunc myapp:latest
docker save myapp:latest | tar -xO | \
  grep -r "email\|password\|secret\|token" --include="*.json" 2>/dev/null

Phase 2: Generate SBOM for Art.25 documentation

# Using Syft (integrates with Harbor's built-in scanner)
syft packages myapp:latest -o spdx-json > sbom-myapp-$(date +%Y%m%d).json
cosign attest --predicate sbom-myapp-$(date +%Y%m%d).json \
  --type spdxjson registry.example.eu/myorg/myapp:latest

Phase 3: Mirror existing images to EU registry

# Using Skopeo for bulk migration
skopeo copy \
  docker://docker.io/myorg/myapp:latest \
  docker://registry.example.eu/myorg/myapp:latest \
  --dest-creds "user:$(cat ~/.eu-registry-token)"

# Bulk migration script
for TAG in $(crane ls docker.io/myorg/myapp); do
  skopeo copy \
    docker://docker.io/myorg/myapp:$TAG \
    docker://registry.example.eu/myorg/myapp:$TAG
done

Phase 4: Update CI/CD pipelines

# GitHub Actions — before
- uses: docker/build-push-action@v5
  with:
    push: true
    tags: myorg/myapp:latest

# After — push to EU registry
- uses: docker/build-push-action@v5
  with:
    push: true
    registry: registry.example.eu
    tags: registry.example.eu/myorg/myapp:latest

Phase 5: Configure Harbor pull-through proxy for Docker Hub base images

Harbor's proxy cache lets you pull Docker Hub images through your EU registry without direct dependency on Docker Hub from developer machines or CI runners:

# harbor/registries/dockerhub.yaml
provider: docker-hub
name: dockerhub-proxy
url: https://hub.docker.com
access_key: your-dockerhub-username
access_secret: your-token

After enabling, replace FROM ubuntu:22.04 with FROM registry.example.eu/proxy-dockerhub/ubuntu:22.04. Docker Hub is now accessed from your EU registry server — pull logs stay in your jurisdiction.

Art.30 Documentation Template

Processing activity: Container image storage and distribution
Controller: [Your organisation]
Processor: [Harbor / Forgejo — self-hosted EU infrastructure]
Legal basis: Art.6(1)(f) — legitimate interest in software supply chain integrity
Categories of data: Software artefacts (may include build-time configuration
  referencing employee or user identifiers)
Third-country transfers: None (EU-only infrastructure — DE/FI/NL)
Retention: Image tags retained per release lifecycle;
  untagged layers GC'd on [schedule]
SBOM: Stored as OCI referrer artefacts, Syft/Cosign signed
NIS2 supply-chain assessment: Completed [date], risk: Low
  (self-hosted, air-gapped option available)

The Comparison: Docker Hub vs EU Self-Hosted

Conclusion

Docker Hub is the default, but default is not compliant. The combination of US jurisdiction under CLOUD Act, architectural limitations on Art.17 erasure, and NIS2 supply-chain obligations makes a compelling case for migrating to a EU-sovereign container registry before your next DPA audit.

Harbor on Hetzner is the enterprise-grade choice: CNCF-graduated, production-hardened, with built-in SBOM and vulnerability scanning. Forgejo is the right answer for organisations that want a complete EU-native software forge with integrated registry and no dependency on any US entity — not even a US-headquartered open-source foundation.

The migration is a one-time operational cost. The compliance risk of staying on Docker Hub is ongoing.

sota.io runs entirely on EU infrastructure. Every container we build and deploy stays within EU jurisdiction. Sign up and deploy your first container in 60 seconds — no US cloud required.