Best European Alternatives to Docker Hub

Why people leave Docker Hub

Docker Hub is rarely a choice anybody made. It is where the base image lives, so it is where every build goes, and it stays that way until a pipeline starts failing with a message about a rate limit.

That is the usual trigger. Anonymous pulls are capped at 100 per six hours, counted per IPv4 address or IPv6 /64 subnet, and a free Docker Personal account gets 200 per six hours.

A build farm behind one NAT gateway is a single address as far as the counter is concerned, so a dozen developers and a busy CI queue share one bucket. Paid plans are described as unlimited subject to fair use, and the documentation warns that excessive transfer, pull rates or storage can lead to throttling or additional charges — unlimited, then, but not a number.

The jurisdiction question sits underneath it and is unusually plain here. Docker, Inc. operates from Palo Alto, its privacy policy states that Docker and its services are based and provided primarily in the US, and transfers out of the EEA run on the EU-U.S. Data Privacy Framework and standard contractual clauses. There is no European region of Docker Hub to select, so unlike a forge, this is not a configuration question.

• The meter counts your address, not your team Rate limits on anonymous pulls apply per IPv4 address or IPv6 /64 subnet, which is exactly the wrong unit for modern infrastructure. Every runner in a Kubernetes cluster behind one egress address draws from the same 100 pulls per six hours, and a multi-architecture image counts once per architecture pulled. Authenticating helps, paying helps more, and neither changes the fact that your build reliability depends on somebody else's counter.
• Docker cannot even agree with itself about the free tier The documentation says a free Docker Personal account gets 200 pulls per six hours; the pricing table for the same plan says 100 pulls per hour. Both pages are current, both are Docker's. When you are sizing a build pipeline, the gap between those two numbers is the difference between a green pipeline and a red one, and the fix is not to pick the friendlier figure — it is to stop depending on the figure.
• There is no European Docker Hub to switch on Several American vendors answer the sovereignty question with a region selector. Docker does not: the privacy policy puts the services in the United States and leans on the Data Privacy Framework and standard contractual clauses for transfers, and there is no residency add-on to buy. For a regulated buyer that simplifies the decision, because the only way to keep images in Europe is to keep them somewhere else.
• "Unlimited, fair use" is a policy, not a quota Paid plans remove the pull counter and replace it with a judgement. The usage documentation reserves the right to throttle or charge for excessive data transfer, pull rates or storage without publishing where excessive begins. That is defensible for a free service funded by paid ones, and it is a poor foundation for a release process you are contractually obliged to run at two in the morning.

What you have to replace, not just match

Docker Hub does three jobs and they detach cleanly, which is why this migration is usually easier than a forge migration and more often done badly.

The first is the private registry: your own images, pushed by CI and pulled by your servers. That moves to any of the options below in an afternoon, because the registry API is a standard and the only real work is credentials. The second is public distribution: the images you publish for other people, where Docker Hub's value is the audience and the fact that docker pull works with no configuration.

The third is the one teams forget. Every Dockerfile that begins with a bare image name is still pulling from Docker Hub after the migration, so your build depends on it whatever you did with your own images. The fix is a pull-through cache or a mirror of the upstream images you actually use, held in the registry you now control. Do that first and the rate limit stops mattering the same week.

The alternatives compared

How each alternative compares to Docker Hub

What actually breaks when you switch

The inventory is the job. Image names hide in Dockerfiles, Compose files, Helm values, Kubernetes manifests, Terraform, CI configuration and the odd shell script, and every one of them has to be found before the old credentials are revoked. Grep for the registry hostname, then grep again for bare image names, because those are the ones still pointing at Docker Hub.

Digests and tags will bite once. Anything pinned by digest has to be re-pinned after the copy, because the digest follows the content and the tooling that verifies it does not care about your migration. Copy with a tool that preserves multi-architecture manifests rather than pulling and pushing on one machine, or your ARM users will find out before you do.

And keep the old account alive longer than feels necessary. A registry migration is discovered by whatever runs quarterly — a disaster recovery drill, a customer's air-gapped installer, a scheduled rebuild of a base image. Leave the Docker Hub repositories in place, read-only, until one full cycle of those has passed.

Will moving our images actually stop the rate-limit failures?

Only partly, and this is where most migrations stall. Pushing your own images elsewhere removes your images from Docker Hub's counter, but every FROM line that names an upstream image still pulls from Docker Hub, and those are the pulls a CI fleet makes most often.

The complete fix has two halves: your registry for your artefacts, and a cache or mirror in front of the upstream images you depend on. Harbor, which is what OVHcloud runs as a managed service, does proxy caching of remote registries natively; with a plain registry the equivalent is a scheduled job that copies the handful of base images you actually use into your own namespace and a policy that Dockerfiles reference those.

Teams that do only the first half report that the pipeline still fails, just less often, and conclude the move was pointless. It was half a move.

Is a registry inside our git platform enough?

For most teams, yes, and it is the cheapest option to adopt because there is nothing new to buy or authenticate against. GitLab ships a container registry on every tier, on GitLab.com, on self-managed installations and on Dedicated, speaking both Docker V2 and OCI, and the CI job already has a token that can push to it.

The argument against is concentration. Your source, your pipelines and your artefacts then share one platform, one outage and one compromise, and a registry sized for a forge is not sized for a monorepo producing hundreds of image tags a day.

The split most organisations end up with is unremarkable and sensible: images from CI go into the forge registry, production pulls from a dedicated registry in the same region as the cluster, and the two are kept in step by the pipeline.

Does it matter which European country the registry sits in?

Less than which region your cluster is in, and that surprises people who arrive with a sovereignty question. A registry two hundred milliseconds and one egress bill away from the machines pulling from it is a slow, expensive registry regardless of the flag on it.

Scaleway keeps every data centre inside the EU — Paris, Amsterdam and Warsaw — which makes it the straightforward answer when the workload already runs there, because the pull never leaves the region. OVHcloud spans more than thirty data centres and holds SecNumCloud from the French agency ANSSI, which is the qualification that appears in public-sector procurement where GDPR alone is not a sufficient answer.

Pick the one your compute is already in. Then check the egress terms, because that is where a registry quietly becomes expensive.

What happens to the images we publish for other people?

They lose their doorstep. An image on Docker Hub is pulled by name with no configuration, and that convenience is the entire reason to publish there; every alternative requires users to type a registry hostname first.

For a free software project, publishing alongside the source is a reasonable answer: Codeberg's package registry accepts container images, so the release and the code that produced it sit in one place under one licence. For a commercial vendor distributing to customers, keep the Docker Hub presence for distribution and move the internal pipeline elsewhere — those are different problems and only one of them is yours to solve.

Either way, announce the new location in the repository and keep the old tags in place. Nothing annoys downstream users like an image that stops receiving updates without saying where it went.

Which one to pick

If the problem is failing builds and an unpredictable counter, OVHcloud is the one to look at first, because Harbor can cache the upstream images your pipelines pull and the traffic is inside the plan rather than on the invoice.

If your workload already runs on European infrastructure, put the registry in the same region as the compute: Scaleway keeps everything in Paris, Amsterdam or Warsaw, and a local pull is both the cheap answer and the fast one.

If the images are purely an output of your pipeline and never leave the company, GitLab's registry is the least work of anything here — and only a self-managed or Dedicated instance changes the jurisdiction, which the hosted version does not.

If the project is open source, Codeberg will host the image beside the code for nothing, under rules its members voted on. And whichever you choose, mirror the upstream base images you depend on, or you will have moved your artefacts and kept the dependency that was breaking your builds.