SDLC, DevOps & Developer Experience · Chapter 11 of 15
Artifact registries, and what immutable actually means
Where your binaries live, the free tier that silently stops accepting them, and why 'we require immutable tags' is four different implementations.
The artifact registry is the least discussed and most load-bearing component in a delivery pipeline: it holds the thing you actually ship. This chapter is what the products are for and the specific ways each surprises you.
The categories
| Category | Products | What it is genuinely for |
|---|---|---|
| Universal binary stores | Artifactory, Nexus | The only serious answer when you must serve thirty package formats from one governed place, with replication |
| Cloud-native container registries | The three clouds' own registries | Cheap, integrated, and free to pull from within the same region — which is the whole argument |
| Platform-bundled registries | The source platforms' package registries | Convenient because they are already there. Included tiers are small; not a serious enterprise binary store |
| Hosted multi-format | Cloudsmith and similar | The 'I do not want to operate Artifactory' option, with good regional delivery |
| Self-hosted container registry | Harbor | Free, CNCF-graduated, with the most expressive immutability rules of any product here |
The free-tier trap that is a production incident waiting to happen.
One major self-hosted registry's community edition has usage limits — and those limits were tightened on existing users in a late-2025 release, roughly halving the allowed component count and cutting the daily request allowance.
When either threshold is exceeded, new component ingestion pauses until usage drops back below both. A free registry that silently stops accepting artifacts mid-sprint is not a licensing inconvenience; it is an outage in your delivery pipeline, and the failure mode is confusing because everything else keeps working.
The general lesson, which recurs throughout this chapter: read the limits, not the badge. ‘Free and open source’ and ‘free with usage limits that can be reduced under you’ are very different propositions, and only one of them belongs in a build pipeline.
Immutable tags: four incompatible implementations
Every security standard says to use immutable tags, and the term means four different things depending on the product. Anyone writing a policy across a mixed estate is writing four implementations.
| Design | How it works | Usability |
|---|---|---|
| Repository-level with exclusions | Immutable by default, with wildcard patterns exempting specific tags such as a moving latest | The most usable design. It matches how teams actually work — pinned releases immutable, one moving pointer allowed |
| Repository-level, absolute | Set at repository creation, all or nothing | Workable, and it forces a separate repository for anything that must move |
| Per-tag manual locking | Each tag is individually marked read-only after push | Effectively unusable at scale without automation, because it is a post-push step someone must remember |
| Pattern rules | Project-scoped rules matching tag patterns | The most expressive, on a self-hosted product |
| Not supported natively | Enforced through permissions and policy instead | This is where the two largest enterprise binary stores sit — a fact worth knowing before you write the policy |
The practical consequence: deploy by digest rather than by tag, everywhere. A content digest is immutable by construction and requires no registry feature at all, which makes it the only portable answer. Tag immutability is a helpful defence in depth; the digest is the actual control.
The charges that surprise people
- Storage measured at the high-water mark on at least one hosted product — the peak stored during the billing period rather than the average. One afternoon of publishing debug builds sets your bill for the month.
- Shared storage pools. On the platform-bundled registries, package storage shares a quota with build artifacts, so a chatty CI pipeline consumes your registry allowance.
- Scanning billed separately. Cloud registries typically offer basic scanning free and route deeper scanning to a separate security product with its own meter. Teams enable it and are surprised by a line item under a different service name.
- Egress. Pulling within the same region is generally free and pulling across regions or out to the internet is not — which makes registry placement a real architectural decision for a multi-region cluster estate.
- And retention. Every registry accumulates. Untagged manifests, old builds, abandoned branches. A retention policy is the cheapest cost control here and it is almost never configured until someone looks at the bill.
Check yourself