Container Hub

Self-hosted container registry management, honestly reviewed. No marketing fluff, just what you get when you point a UI at your own registry.

TL;DR

• What it is: A small, open-source web UI for browsing and managing Docker/OCI registries — think a visual front-end for the bare Docker Registry v2 API [README].
• Who it’s for: DevOps engineers and self-hosting teams who run their own private Docker registry and want something better than the command line to browse images and tags [README].
• Cost savings: Managed registries like Docker Hub ($5–15/user/mo) and AWS ECR ($0.10/GB + egress) add up quickly at scale. Container Hub itself is free; you just need the VPS running your registry [4].
• Key strength: Remarkably simple to bolt onto an existing Docker registry — one Docker Compose service, two environment variables, done [README].
• Key weakness: Pre-v1.0 software with a documented scaling problem: the author explicitly warns it “doesn’t scale efficiently — even for relatively small projects (e.g., repositories with 100+ tags)” [README, issue #28]. Also 178 GitHub stars as of this review — this is a small, one-person project, not an established tool.

---

What is Container Hub

Container Hub is a web-based UI that sits in front of a Docker Distribution (v2) registry and gives you a visual way to explore repositories, list tags, and delete images. The GitHub description reads “Yet another docker registry UI” — which is an unusually honest self-description [README]. The project author (eznix86) isn’t pitching a platform or a company. They’re shipping a tool.

To be clear about what it is and isn’t: Container Hub is not a registry. It doesn’t store images. It wraps an existing registry — typically the open-source Docker Distribution project or a compatible v2 endpoint like GHCR — and provides a browser interface for what would otherwise require docker image ls and curl commands against the registry API.

The features you get are what you’d expect from a minimal v2 API wrapper: view repositories, list tags, trigger garbage collection, delete images. What you don’t get is what Harbor or Quay offer — vulnerability scanning, image signing, RBAC, audit logs, LDAP integration [3][4]. Those are completely different tools solving a different set of problems.

The website listed in the project metadata (https://nostr-auth.brunobernard.dev) appears to be an unrelated personal development project. There is no product homepage for Container Hub. The README on GitHub is the primary documentation.

---

Why people choose it

The honest answer is that most people choosing Container Hub aren’t doing a feature-by-feature comparison — they’re running a small self-hosted Docker setup and want to stop typing curl -u user:pass https://registry:5000/v2/_catalog to see what they have.

The broader context is that self-hosting container registries is a growing practice. As Cyso Cloud put it: “When the place you store container images is not bound to a platform: you can move it, replicate it, or redeploy it elsewhere” [4]. When you’re pulling from a self-hosted registry in CI/CD, you’re not subject to Docker Hub rate limits or GHCR token scoping changes. But the bare Distribution registry has essentially no UI. That’s the gap Container Hub fills.

For teams running on-premise or on their own VPS, running Docker images on a mini PC server farm, or building air-gapped setups, a lightweight UI that needs zero configuration beyond a registry URL is attractive [1]. The alternative is either Harbor (genuinely powerful, but requires PostgreSQL, Redis, and a Helm install that takes 30 minutes on a good day) or Portainer (broad container management, much heavier) [3][4]. Container Hub promises to be the option that takes five minutes.

What I couldn’t find: any independent user reviews, Trustpilot entries, Reddit threads specifically about Container Hub, or third-party benchmarks. At 178 stars, the user base is too small to have generated a public opinions trail. Take this review with that in mind — I’m working from the README and what’s known about this category.

---

Features

Based on the README:

Core registry browsing:

• List repositories and tags across connected registries [README]
• View image metadata [README]
• Delete images (with the important caveat below on garbage collection) [README]
• Multiple registry support via REGISTRY_URL_* environment variable suffixes — you can connect to several registries at once [README]
• GitHub Container Registry (GHCR) support as of v0.5.0 [README]
• Unauthenticated registry support as of v0.3.2 — REGISTRY_AUTH can be omitted [README]

Authentication:

• Basic auth via base64-encoded username:password [README]
• Per-registry auth — each suffix gets its own REGISTRY_AUTH_* variable [README]
• No OAuth, no SSO, no LDAP. Basic auth only.

Deployment:

• Docker Compose (single service, two env vars) [README]
• Kubernetes via Helm chart (helm repo add docker-registry-ui https://eznix86.github.io/docker-registry-ui) [README]
• Kubernetes secrets integration for credential management [README]

What’s missing (compared to Harbor or Quay):

• No vulnerability scanning [3][4]
• No image signing [4]
• No RBAC — anyone who can reach the UI can browse everything [4]
• No audit logs [4]
• No image replication [4]
• No retention policies [3]
• No quota management [3]

One important operational note the README surfaces honestly: deleting images in Docker Registry v2/v3 doesn’t reclaim disk space automatically. You have to run garbage-collect inside the registry container manually after deletions. Container Hub can trigger a delete via the UI, but the actual disk reclamation is a separate step [README].

---

Pricing: SaaS vs self-hosted math

Container Hub itself has no pricing — it’s open source, no license listed, free to run.

The relevant cost comparison is what you’re avoiding by running your own registry with a UI like this, versus paying for managed registry services:

Managed registry options:

• Docker Hub: Free tier allows 1 private repository with rate limits on pulls. Pro: $5/mo (unlimited private repos). Team: $15/user/mo.
• GitHub Container Registry (GHCR): Included with GitHub plans. Free for public packages; private packages consume GitHub Actions storage (1GB free, then $0.008/GB/day).
• AWS ECR: $0.10/GB/month storage + standard data transfer fees. Adds up fast if you’re storing many large images or pulling frequently in CI/CD.
• Google Artifact Registry: $0.10/GB/month after 0.5GB free. Similar egress fees.
• Azure Container Registry: Starts around $0.167/day for the Basic tier (~$5/mo).

Self-hosted math:

• Docker Distribution registry: free [4]
• Container Hub UI: free [README]
• VPS to run both: $4–6/mo on Hetzner or Contabo for a basic setup
• Storage: whatever local disk you provision, no per-GB billing

For a team pulling 50GB of images per month from AWS ECR, that’s $5/mo in storage plus potentially $4–6/mo in data transfer. On your own VPS with unlimited local disk, that’s your monthly VPS cost amortized against everything else you run on it [4]. At five to ten developers, the math clearly favors self-hosting if someone is willing to manage it.

The catch: this calculation only holds if you’re willing to run the registry infrastructure. Container Hub adds zero management overhead — it’s a stateless UI — but the registry underneath needs backups, garbage collection, and operational attention [README][4]. “Free” software still has a maintenance cost.

---

Deployment reality check

Getting Container Hub running is genuinely fast if you already have a registry. The Docker Compose snippet in the README is two services and four lines of environment config. Point it at your existing registry URL, set the base64-encoded auth, and open http://localhost:8011 [README].

Helm install on Kubernetes is a bit more involved — you’ll create a namespace, a secret for credentials, and override the values file with your registry connection details. The README covers this completely [README]. Not hard, but it assumes you know Helm and kubectl.

What can go sideways:

The biggest known issue is documented by the author himself: the current version doesn’t scale efficiently for registries with 100+ tags per repository. The author has opened a tracking issue (#28) and is working toward a v1.0.0 rewrite to address this. If you’re managing a large production registry with hundreds of image versions per service, this will be painful today. If you’re a small team with modest tag counts, you probably won’t hit this [README].

No independent stress tests exist that I can reference. Given 178 stars, no one has published a “we ran this at scale” postmortem.

Realistic estimates:

• Developer with existing Docker registry: 5–10 minutes to a working UI
• Kubernetes operator deploying via Helm: 20–30 minutes including secret creation and values tuning
• Someone setting up Docker Distribution + Container Hub from scratch: 1–2 hours including reverse proxy, TLS, and registry configuration

---

Pros and Cons

Pros

• Minimal surface area. Single container, two environment variables, no database, no persistent state. This means nothing can break in the UI layer itself [README].
• Multiple registry support out of the box. Suffix-based env var pattern (REGISTRY_URL_PERSONAL, REGISTRY_URL_BUSINESS) is clean and Kubernetes-friendly [README].
• GHCR support. Most lightweight Docker registry UIs don’t bother with GHCR’s PAT-based auth. This one does [README].
• Honest documentation. The README calls out the scaling problem, links the tracking issue, and asks for community input. That’s better project hygiene than tools with 10x the stars and buried bug trackers [README].
• Helm chart exists. Many small projects stop at Docker Compose. Having a published Helm chart for Kubernetes deployment is a real convenience [README].
• Zero vendor lock-in. It’s a read/write UI against the open Distribution v2 API. If you switch UI tools, nothing changes about your registry [4].

Cons

• Pre-v1.0 with a documented scalability bug. The author explicitly flags that the current architecture doesn’t handle 100+ tags per repo efficiently. This isn’t speculation — it’s in the README warning banner [README].
• No security features. No vulnerability scanning, no RBAC, no audit logs, no image signing [3][4]. If any of those matter to you, you need Harbor, not this.
• 178 GitHub stars. This is the honest number. A project this small may be abandoned, may have undiscovered bugs, and has no community to answer questions. You’re mostly on your own [merged profile].
• No product website. The listed website is an unrelated personal project. There’s no docs site, no changelog page, no support channel beyond GitHub issues.
• Basic auth only. No LDAP, no OIDC, no SSO [README]. For anything beyond a personal or small-team registry, this is a hard limitation.
• Manual garbage collection. Deletions via the UI don’t reclaim disk space — you have to run garbage-collect inside the registry container separately [README]. Easy to forget, leads to disk exhaustion.
• No REST API or webhooks. You can’t programmatically query Container Hub or trigger UI actions from CI/CD.

---

Who should use this / who shouldn’t

Use Container Hub if:

• You already run Docker Distribution on a self-hosted VPS and want a quick browser window into it.
• You’re a solo developer or very small team with a modest registry (under 100 tags per repo, for now).
• You want the absolute minimum viable UI with no operational overhead.
• You’re comfortable self-hosting without vendor support.

Skip it (use Harbor instead) if:

• Your team needs RBAC, vulnerability scanning, image signing, or audit logs [3][4].
• You’re running a production Kubernetes environment with compliance requirements [3][4].
• Your registry has hundreds of tags per repository — Harbor handles this without flinching [3].
• You need replication between registry instances or disaster recovery tooling [4].

Skip it (use Docker Hub or GHCR) if:

• You don’t want to manage registry infrastructure at all.
• Your team is already inside the GitHub ecosystem and GHCR’s package storage is included in your plan.
• You have fewer than a handful of private images and managed hosting costs are negligible.

Skip it (use Portainer) if:

• You want broader container management (stack deploys, container logs, resource monitoring) alongside registry browsing. Portainer covers registry management as part of a full container management platform, though it’s heavier to run.

---

Alternatives worth considering

• Harbor — The serious self-hosted container registry. Full RBAC, built-in Clair/Trivy scanning, image signing, replication, LDAP/OIDC support, quota management. Heavy to deploy (PostgreSQL + Redis + multiple services), but production-grade [3][4]. If you need any enterprise feature, Harbor is the answer.
• Docker Registry (Distribution) — The bare registry with no UI. Free, minimal, maintained by the CNCF. Pairs well with Container Hub or any other UI layer [4].
• Quay (Red Hat) — Enterprise-focused, supports robot accounts and team management, integrates with OpenShift. More opinionated than Harbor, not as commonly self-hosted outside Red Hat environments.
• Gitea Container Registry — If you’re already running Gitea for source control, its built-in container registry is a reasonable option that avoids running a separate service [4].
• Portainer — Broader container management platform that includes basic registry management. More RAM and disk than Container Hub, but covers a lot of ground in one install.
• docker-registry-browser (klausmeyer) and Joxit Docker Registry UI — Other lightweight open-source UI projects in the same category as Container Hub. More stars, more community history.

The realistic decision tree: if you need security and compliance features, run Harbor. If you just need to browse a personal registry, Container Hub or one of its peer projects works fine.

---

Bottom line

Container Hub is exactly what it says it is: yet another Docker registry UI. It solves a narrow problem cleanly — giving you a browser window into a Docker Distribution registry that would otherwise require curl commands and API spelunking. The deployment story is as simple as self-hosted tools get: one container, two environment variables.

The honest caveats are significant: this is pre-v1.0 software from a single developer with 178 GitHub stars, a known scaling bug for larger registries, and no security features beyond basic auth. For a solo developer or two-person team running a modest private registry, none of those caveats are blockers. For anyone with compliance requirements, a large team, or a registry with hundreds of image tags, use Harbor.

What Container Hub is not is a replacement for Harbor, Quay, or managed services like Docker Hub. It doesn’t try to be. In the self-hosting world, a tool that does one thing simply and deploys in five minutes has genuine value — as long as you’re clear-eyed about where its limits are.

If setting up any of this infrastructure sounds like more than you want to own, that’s the kind of one-time deployment work upready.dev handles for clients.

---

Sources

1. Ernie Smith, Tedium — “Self-Hosting Tools: Still Worth Trying In 2026?” — tedium.co. https://tedium.co/2026/03/28/self-hosting-platform-tools-guide/
2. Grouchy_Way_2881, r/devops — “Built a self-hosted, containerized dev environment — looking for honest DevOps feedback” — reddit.com. https://www.reddit.com/r/devops/comments/1jzzj8n/built_a_selfhosted_containerized_dev_environment/
3. MIHIGO Justin, Medium — “Harbor self hosted container registry” — medium.com. https://medium.com/@mihigojustin28/harbor-self-hosted-container-registry-b619e1583fd8
4. Noa Omer, Cyso Cloud — “Why Self-Hosting Your Container Registry Makes Sense” — cyso.cloud. https://cyso.cloud/blog/why-self-hosting-your-container-registry-makes-sense-especially-now

Primary sources:

• GitHub repository and README: https://github.com/eznix86/docker-registry-ui (178 stars)
• Docker Distribution garbage collection: https://distribution.github.io/distribution/about/garbage-collection/