Container and Package Registries¶
Once you know an artifact needs a durable home, the next question is which kind of registry holds it. This page covers the two shapes a DevOps junior actually runs into: container-only registries (GHCR, ECR, Docker Hub) and universal repository managers (Nexus, Artifactory) that hold containers and language packages side by side.
TL;DR — in 30 seconds:
- GHCR, ECR, and Docker Hub are container-image registries — simple, cloud/platform-native, and usually the right default if containers are the only artifact type you publish.
- Nexus and Artifactory are universal repository managers: one system fronting containers, npm, Maven, PyPI, and generic files, with one access-control model across all of them.
- Reach for a universal repo manager when a team publishes multiple artifact formats and wants one place to manage access, retention, and auditing for all of them — not just containers.
1. Container-only registries¶
| GHCR (GitHub Container Registry) | Amazon ECR | Docker Hub | |
|---|---|---|---|
| Native integration | GitHub repos, GitHub Actions | AWS IAM, ECS/EKS | Docker CLI, any CI |
| Private repos | Free (tied to a GitHub account/org) | Pay for storage + data transfer | Free tier limited, paid for more |
| Typical fit | A project already living on GitHub | An AWS-native stack | Public images, or teams outside AWS/GitHub |
All three are OCI-compliant: docker push/docker pull (or any OCI-compatible client) work the same way
against any of them, just pointed at a different registry hostname. The choice is mostly about where your
pipeline and infrastructure already live — GHCR if you're GitHub-native, ECR if you're AWS-native, Docker
Hub if neither applies or the image needs to be public.
2. Universal repository managers¶
flowchart LR
A["CI pipeline"] -->|"container image"| R["Nexus / Artifactory"]
A -->|"npm package"| R
A -->|"Maven artifact"| R
A -->|"generic binary"| R
R -->|"one access model,<br/>one audit trail"| C["Every consumer"]Sonatype Nexus Repository and JFrog Artifactory both front multiple package formats — container images, npm, Maven, PyPI, and generic files — behind a single system. That buys:
- One access-control model instead of a different permission system per format's own registry.
- One retention/lifecycle policy engine applied consistently across every artifact type.
- One audit trail for "who pulled what, when," across the whole software supply chain, not just images.
Both ship a free/community edition (self-hosted, core proxying and hosting features) and a paid professional edition (advanced replication, more granular policies, vendor support). The tradeoff versus a container-only registry is operational: you're running (or paying for) one more system, in exchange for not running five different registries for five different package types.
Common gotchas
- Standing up a universal repo manager for a team that only ever publishes container images. Fix: if containers are the only artifact type, a container-only registry (GHCR/ECR/Docker Hub) does the job with less operational overhead — reach for Nexus/Artifactory when multiple formats are actually in play.
- Assuming every registry enforces the same rules by default. Fix: features like tag immutability and retention policies (next page) are usually opt-in configuration, not automatic — check the specific registry's settings rather than assuming.
Check yourself — a team publishes container images, npm packages, and Maven artifacts, and wants one place to manage access and retention for all three. What should they reach for, and why?
A universal repository manager (Nexus or Artifactory) — a container-only registry like GHCR or ECR doesn't host npm or Maven artifacts at all, so the team would otherwise need three separate systems with three separate access-control and retention setups instead of one.
Done when: you can name, for a given team's artifact mix, whether a container-only registry or a universal repo manager fits — and say why in one sentence.