Why self-hosting your container registry makes sense, especially now

Why Run Your Own Registry?

Before digging into the options and considerations, why do this in the first place?

Below are common motivation points, the weight of these is dependent on your organisation and/or use case:

• Internal Images
  Many base images, build artefacts, and production images are proprietary. Keeping them off public registries reduces external exposure risk.

• SBOM Generation & Security Scanning
  You want to know exactly what’s in your images. Automatic vulnerability scans, generation of software bills of materials (SBOM), and enforcing policies around image content are much easier when the registry is under your control.

• Compliance and Security
  Fine-grained RBAC (role-based access control), integration with enterprise IAM (e.g. LDAP, AD, etc.), audit logs and general observability of your registry... These are often missing or limited in hosted solutions unless you pay a premium.

• Replication & Fail-over
  Having your own registry gives you full control over where images are stored, replicated, and backed up. You can deploy replicas close to your compute environments, and set up failovers in case of region or provider outage.

• Platform Independence & Vendor Lock-In Avoidance
  When the place you store container images is not bound to a platform: you can move it, replicate it, or redeploy it elsewhere. Your CI/CD, image pull policies, and internal tooling are not tied to a specific cloud provider or vendor ecosystem. Does this require planning and testing? Yes, but these aren’t complicated pieces of software and you’re very unlikely to run into issues with the underlying hardware or Kubernetes platform.

If these pain points or wanted features are familiar and are lacking in your current use of Docker Hub or GitHub/GitLab registries, then you’re likely to benefit from self-hosting. We’re going to dig into two options below.

Software Options: Harbor vs Docker Registry

There are two leading open source/self-hosted options that aren’t freemium: Harbor and Docker Registry.

Do keep in mind that Docker Hub and Docker Registry are two different things; the latter is based on the CNCF ‘Distribution’ project and is open source.

Below is a quick overview of these two options, and there are more comprehensive write-ups on this topic. 

I’ve made a table mapping features (on usability, integration, compliance, ease of use fronts) below:

(One small point - these are static container image registries, which are the only ones available at the moment. Cyso Cloud was at CDS 2025 in Hamburg and an interesting development in the container registry space is the movement towards more dynamic registries. Ones that combine together different image layers based on what is requested. An example given by Alvaro Hernandez at CDS was a dynamic registry that dynamically put together PostgreSQL images with your own choice of extensions and versions based on the pull command given to the registry. Slide Deck (not from CDS but same topic/author)

Once you’ve made a choice, the follow-up is the question: how to run it and where? We’ll cover that down below.

Deployment Model vs Placement

When thinking about where and how to host a registry, it helps to separate the deployment model from placement. The deployment model describes how you operate the service: some teams start simple by running the registry as a standalone container or virtual machine, perhaps backed by local storage. Others embed it into their Kubernetes clusters, using Helm charts or operators to handle lifecycle and scaling. More advanced setups treat the registry as part of a managed internal platform, complete with monitoring, policies, and quotas. And in environments with global users or strict uptime needs, registries are often distributed across multiple sites, with replication and failover strategies baked in. This depends on the software you choose (be it Harbor, Docker Registry or one of the other myriad of options) and your needs.

Placement determines where the registry physically runs. At one end of the spectrum is your own infrastructure, in a colocation rack or in your own server rack, where you carry the full operational responsibility and have to develop on top of it.

A step up from that is running on your own private cloud, for example, an OpenStack, VMWare or CloudStack environment that you manage across one or multiple sites. Again, full operational responsibility, but these cloud platform layers provide a degree of flexibility (i.e. for migrating it as an outsource measure) and features. CAPEX intensive at first though.

Beyond that are sovereign or regional providers, many of them also based on OpenStack, such as our Cyso Cloud in the Netherlands, which combines cloud convenience with local jurisdiction and open standards. Finally, there are the global hyperscalers: AWS, Google Cloud, Azure and a few others, whose reach and tooling are unmatched. Beware that these ecosystems create lock-in, high egress costs, and compliance considerations and are where geopolitical considerations can be an important factor. All of these options are more OPEX intensive in return for much smaller entry costs.

Do keep in mind that hyperscalers like to get their consumers locked in before jacking up the price, as seen with Google Cloud’s egress costs for object storage. Even closed-source self-hosted options can be problematic, as seen in the increased licensing costs from Broadcom's acquisition of VMware. Lift and shift shouldn’t be one-way. Being agile with the components that make up your platform keeps costs down over the long run and lowers the risk that your platform (or part of it) is the victim of rising per-core licenses or geopolitical decision-making.

Conclusion

Self-hosting your container registry is not boiled down to a technical preference, it is a safeguard. By decoupling your registry from source control, you give yourself the freedom to move platforms when needed, as we experienced moving from GitHub to Gitea. By choosing open-source options like Harbor or the simpler Docker Registry, you avoid the hidden strings of freemium licensing and can be certain you won’t have features taken away from you.

The decision of how and where to deploy matters just as much. Whether you run it bare on your own servers in containers, in your own Kubernetes deployment, or on a managed platform, the registry should be treated as a first-class infrastructure service. Placement then defines your trade-offs: your own racks and private clouds give maximum control at the cost of CAPEX, sovereign OpenStack providers such as Cyso Cloud provide regional independence and open standards, and hyperscalers offer scale and convenience but at the price of lock-in and long-term cost uncertainty.

Taken together, self-hosting your container registry application ensures that a core part of your software delivery pipeline remains under your control. In a landscape of shifting regulations, acquisitions, and pricing models, having that independence means you can adapt without disruption. The registry is small compared to other components of your platform, but strategically, it is one of the easiest wins in retaining platform resilience and freedom of choice.