- Container registries at a glance
- Eleven registries for container images
- Matching a registry to where you deploy
- Registries get retired, so plan for moves
- Managed cloud registries versus self-hosted ones
- Questions to ask before you pick a registry
- Signs it's time to rethink your registry
- My plain advice on choosing a container registry
- Frequently asked questions
The best container registries store your Docker and OCI images securely and serve them quickly to the servers and clusters that run your apps. Some are managed registries from the big clouds, while others are open source projects you host yourself or artifact platforms that hold every kind of package. Eleven options follow in no particular order.
Every deploy starts with pulling an image, so the registry quietly sits in the middle of everything. If it's slow, down or exposed, your releases are slow, down or exposed too.
The eleven container registries below are listed alphabetically and in no particular order, and every description comes from the provider's own website or documentation, read this week. If you're building out the team that runs all this, my guide to finding remote DevOps talent may help.
Container registries at a glance
I checked the free plan column on each tool's own website, as of Oct 2026. Yes means the site names a free plan, a free version, a free allowance or an open source version. Trial only means a time-limited trial. Not stated means the pages I read named neither, even where there's a button inviting you to start for free, so check the vendor's page before you sign up.
| Tool | Type | Good for | Free plan |
|---|---|---|---|
| Amazon ECR | Fully managed container registry | Teams deploying on AWS | Not stated |
| Azure Container Registry | Managed container registry | Teams deploying on Azure | Not stated |
| Cloudsmith | Cloud-native artifact management platform | One home for images and packages | Trial only |
| CNCF Distribution | Open source registry | Building your own registry | Yes |
| Docker Hub | Public and private container registry | Sharing images publicly | Not stated |
| GitHub Container Registry | Container registry inside GitHub Packages | Teams whose code lives on GitHub | Not stated |
| Google Artifact Registry | Artifact and container registry | Teams on Google Cloud | Not stated |
| Harbor | Open source registry | Self-hosting with policies and access control | Yes |
| JFrog Artifactory | Docker and Helm registry | Enterprises managing many artifact types | Not stated |
| Scaleway Container Registry | Managed container registry | Teams wanting a European cloud | Not stated |
| Zot | Open source OCI registry | A lightweight self-hosted registry | Yes |
Eleven registries for container images
Amazon ECR
Best for: AWS-based teams that want a fully managed container registry close to the services that pull their images.
Azure Container Registry
Best for: Microsoft Azure users who want container images managed in the same cloud as their Kubernetes services and container apps.
Cloudsmith
Best for: Teams that want container images and other packages in one artifact platform with policies and logs of what shipped where.
CNCF Distribution
Best for: Platform engineers who want the open source registry code that other registries build on, to run their own private registry.
Docker Hub
Best for: Developers who want the largest public container registry for discovering and sharing images, with private repositories too.
GitHub Container Registry
Best for: Teams whose code already lives on GitHub who want images stored next to the repository, with GitHub permissions.
Google Artifact Registry
Best for: Google Cloud users who want images and other artifacts in one registry, including the move from the older gcr.io service.
Harbor
Best for: Organisations that want a self-hosted, open source registry with policies and role-based access control for their images.
JFrog Artifactory
Best for: Enterprises that want Docker and Helm images in the same artifact platform as their other build outputs, self-hosted or cloud.
Scaleway Container Registry
Best for: European teams who want a managed registry from a European cloud provider for images used in their workloads.
Zot
Best for: Anyone wanting a lightweight self-hosted registry released as open source, with features like garbage collection in a single binary.
Matching a registry to where you deploy
- Deploying on a big cloud: Amazon ECR, Azure Container Registry or Google Artifact Registry.
- Code already on GitHub: GitHub Container Registry.
- Sharing public images: Docker Hub.
- Self-hosting with policies: Harbor or Zot.
- Building your own registry: CNCF Distribution.
- Every artifact type in one place: JFrog Artifactory or Cloudsmith.
- A European cloud provider: Scaleway Container Registry.
Registries get retired, so plan for moves
Google Cloud's Artifact Registry documentation carries a section on transitioning from Container Registry, the older gcr.io service, to Artifact Registry.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
It's a useful reminder that registries change. Keep image locations in configuration rather than hard-coded across dozens of files, and you'll be able to move registries in an afternoon rather than a fortnight.
Managed cloud registries versus self-hosted ones
A managed registry from your cloud provider is the easy choice when your workloads live there. Permissions, networking and billing all sit in the account you already manage.
Self-hosted, open source registries give you full control over where images live and who can reach them. That matters for air-gapped networks and strict data rules, but you're the one keeping it running.
Questions to ask before you pick a registry
- Where are images stored geographically?
- Does it scan images for known vulnerabilities?
- How are pull limits and rate limits handled?
- Can it hold Helm charts and other artifacts too?
- How does access control work for teams and CI?
- Can we replicate images to other regions?
Once images are stored, our Docker hosting roundup covers where to run them.
Signs it's time to rethink your registry
- Deploys stall on image pulls. Move the registry closer.
- Nobody knows which images are in use. Clean up old tags.
- Images aren't scanned. Turn scanning on.
- Registry addresses are hard-coded everywhere. Put them in config.
Do you make a container registry or artifact platform? Tool makers can ask to be considered for a featured place on this list.
My plain advice on choosing a container registry
Keep your registry close to where your containers run. Pull speed and data transfer add up quickly, and a registry in the same cloud region is usually the simplest win you'll get.
Turn on image scanning from day one, and clean out old tags on a schedule so the registry doesn't become a museum. If you're weighing cloud tooling more broadly, my piece on a cloud management suite is a useful wider view.
Frequently asked questions
What is a container registry?
A container registry is a service that stores container images, such as Docker images, and serves them to the machines that run them.
Is there only one public registry?
No. Every major cloud has its own registry, and there are open source registries you can host yourself.
Is there a free open source container registry?
Yes. Several registries in this list are released as open source, so you can run them on your own servers.
What happened to Google Container Registry?
Google's documentation includes guidance on transitioning from Container Registry (gcr.io) to Artifact Registry.
Should my registry be in the same cloud as my apps?
Usually, yes. It keeps pulls fast and permissions simple.
Can a container registry scan for vulnerabilities?
Many can, so check whether scanning is included and how results are reported.

