The State of Artifact Registries 2026

GHCR, Artifactory, Nexus, and the cloud-native registries: adoption, pull latency on the CI critical path, and the storage bill that grows in the dark.

Executive summary

Every container build ends in a push and every deploy begins with a pull, which puts the artifact registry squarely on the critical path of CI. It is one of the least examined parts of the pipeline precisely because it feels like plumbing: teams choose a registry once, wire it in, and rarely revisit the decision even as it quietly accrues latency on every job and storage cost on every tag. In 2026 the market has stratified, and the choice is no longer a default to make once and forget.

The landscape now splits cleanly. GitHub Container Registry is the convenient default for GitHub-centric teams, inheriting their existing auth and sitting next to their code. Artifactory and Nexus hold the enterprise and polyglot-artifact niche, where many artifact types, fine-grained access control, and air-gapped or proxy scenarios matter more than raw speed. And the cloud-provider registries win where workloads already live in a single cloud, because keeping images in that cloud avoids cross-cloud egress and inherits the cloud's identity and access management.

This report quantifies registry adoption and the two costs that actually move the needle in CI: pull latency on the critical path and the steadily growing storage and egress bill. Both are easy to miss in isolation. A single image pull of twenty-odd seconds looks negligible, and a single old tag costs pennies to store, but multiplied across thousands of jobs and millions of forgotten tags they become two of the larger line items in a CI budget, hidden because no single run makes them visible.

The throughline is that registry choice is increasingly an economics and latency decision rather than a feature decision, because the major registries have converged on the features that matter. They all store images, all support immutable tags, all integrate with CI. What separates them now is where they sit relative to the runners that pull from them and how aggressively a team prunes what it stores. Both of those are addressable without switching registries at all.

The most important finding is that runner-side image caching neutralizes most of the latency question regardless of which registry sits upstream. When the runner already holds the base and recently used layers, a pull collapses from tens of seconds to a few, which turns the registry decision back into a pure governance-and-cost question. That reframing matters for engineering leaders: the registry debate that teams agonize over is mostly downstream of a caching decision they have not made yet.

Cloud-provider registries quietly became the default store

Teams that already run their workloads in a single cloud increasingly keep images in that cloud's registry, for two reasons that compound. Cross-cloud egress is a real and recurring cost, so storing images where they are pulled avoids paying to move them across a provider boundary on every deploy. And the cloud registry inherits the cloud's identity and access management, so a team gets policy and audit for free rather than wiring up a separate access model for a standalone registry.

The result is that the cloud registries collectively outnumber any single dedicated product, even though no one of them dominates on its own. The registry-share breakdown shows the cloud-provider category as the largest single slice, ahead of GHCR, with the dedicated enterprise products holding the remainder. This is a consolidation by gravity rather than by preference: images settle where the workloads already are.

GHCR remains the most convenient choice for teams whose center of gravity is GitHub, because it sits next to the code and inherits the same auth the rest of the pipeline already uses. The split is therefore less about which registry is best in the abstract and more about where each team's workloads and code happen to live, which is why the share chart looks like a reflection of the underlying cloud and CI landscape.

Old tags, not active images, drive the storage bill

The largest slice of a registry bill is rarely the images teams pull every day. It is the long tail of old tags that nobody cleans up, every CI build that ever pushed an image, every release candidate, every ephemeral preview tag, accumulating indefinitely because deleting them is nobody's job. The cost-split breakdown puts storage of old image tags as the single biggest line, ahead of the egress that teams more readily blame.

This accumulates because the default behavior of every registry is append-only. A pipeline that pushes an image on every merge will, over a year of active development, leave thousands of tags behind, the overwhelming majority of which will never be pulled again. Each one is cheap individually, which is exactly why no one notices the total until it is a meaningful fraction of the bill.

The fix is to treat the registry as a cache with a time-to-live rather than an append-only archive. Retention policies that prune by age, tag immutability paired with scheduled cleanup of untagged layers, and keeping only the last N builds of a given branch routinely cut storage by a large fraction with no operational risk, because the pruned tags were dead. Teams that automate this stop paying to store a history nothing reads.

• Append-only is the default, so every CI push leaves a tag behind that is rarely pulled again.
• Storage of dead tags outranks CI pull egress as the largest line in the modeled bill.
• Age-based retention and untagged-layer cleanup cut storage sharply with no operational risk.

Pull latency is paid on every cold job

A cold CI job pays the full image pull before it does any useful work, and the pull is pure latency: the job is doing nothing the pipeline exists to do while it waits for layers to arrive. On a cross-region path that wait can be tens of seconds, and the pull-time breakdown shows a cross-region cloud pull and a remote GHCR pull both landing well above a same-region pull.

This latency is invisible in a single run, which is why it survives unexamined for so long. Twenty-two seconds on one job feels like nothing. But CI runs a fan-out matrix thousands of times a month, and the pull is paid on every cold leg of it, so the same twenty-two seconds compounds into hours of aggregate wall-clock that developers wait on and the team pays for. It is a tax levied per job, and the job count is the multiplier.

The two highest-leverage fixes both attack the distance the layers travel. Same-region placement, keeping the registry in the same region as the runners, roughly halves the pull in the model by removing the cross-region hop. And runner-side image caching removes almost all of it, which the next finding covers. Both are configuration changes rather than registry migrations, so the latency is addressable without touching the registry choice at all.

Enterprise registries win on policy, not speed

Artifactory and Nexus persist for reasons that have little to do with pull performance. They handle many artifact types beyond container images, Maven, npm, PyPI, Debian, and more, in one place, which matters for polyglot organizations that would otherwise run a registry per ecosystem. They offer fine-grained access control and the proxying and air-gapped scenarios that regulated and disconnected environments require.

These are governance and breadth strengths, not speed strengths, and the teams that choose them are usually optimizing for control rather than raw latency. That is a legitimate trade, but it does mean an enterprise registry does not by itself solve the pull-latency problem this report is about. A locally hosted Artifactory still serves a cold pull that the runner must wait on before it starts work.

The encouraging part is that the enterprise registries benefit from runner-side caching just as much as the simpler ones, because caching sits on the runner rather than in the registry. A team can keep Artifactory or Nexus for the governance it provides and still collapse pull latency by caching layers on the runner, getting the policy strengths and the speed at the same time rather than choosing between them.

Runner-cached images neutralize the registry latency question

When the runner already holds the base image and recently used layers, the registry pull collapses from tens of seconds to a few, regardless of which registry sits upstream. The pull-time breakdown makes this the dominant effect: the runner-cached path is dramatically faster than every remote path, because most layers are already present and only the genuinely changed ones travel.

This reframes the entire registry decision. If caching removes most of the pull latency, then latency stops being a reason to prefer one registry over another, and the choice reduces to the governance and cost dimensions, where each team's answer is dictated by its workloads and policy needs rather than by speed. The registry debate that teams agonize over is largely downstream of a caching decision they have not yet made.

Managed runners that ship this caching by default turn registry choice back into a pure governance-and-cost decision, and the economics improve on top of the latency. At roughly 70 percent lower cost per minute, the time no longer spent pulling, around $0.0025 per minute of otherwise idle wait, is also cheaper, so the saving is both fewer wasted minutes and a lower price on the minutes that remain. The pull-time chart is the clearest single argument in this report.

• A warm runner cache turns a tens-of-seconds pull into a few seconds by shipping only changed layers.
• With latency removed, registry choice reduces to governance and cost, which workloads already dictate.
• Managed caching at roughly 70 percent lower per-minute cost makes the saved time cheaper too.

Egress is the cost that pull caching also reduces

CI pull egress is the second-largest line in the modeled registry bill, behind dead-tag storage, and it is driven by exactly the same cold pulls that drive the latency. Every layer a cold job pulls across a region or cloud boundary is billed egress, so the fan-out matrix that inflates pull latency inflates the egress bill in lockstep. The two problems share a root cause.

They also share a fix. Runner-side caching does not only make pulls faster; it makes them smaller, because cached layers are not re-transferred and therefore are not re-billed as egress. A team that caches on the runner cuts both the wait and the egress charge at once, which is why caching shows up as a cost lever and a latency lever in the same breath throughout this report.

Same-region placement helps the egress line for the same reason it helps latency: layers that do not cross a region boundary are not billed cross-region egress. Between same-region placement and runner caching, the two largest variable lines in the registry bill, egress and the latency it represents, are addressable without changing registries, which is the practical heart of treating registry choice as configuration rather than destiny.

Registry choice is increasingly configuration, not destiny

Pulling the findings together, the registry decision has far less leverage on CI than teams assume, and the levers that do have leverage sit outside the registry itself. The major registries have converged on the features that matter, so switching between them rarely changes the two costs that actually move the bill: pull latency and storage of dead tags.

Those two costs are governed by decisions a team can make without migrating anything. Latency and egress fall with same-region placement and runner-side caching; storage falls with retention policies and untagged-layer cleanup. None of these requires choosing a different registry, which means a team can keep whatever registry its workloads and governance already dictate and still capture nearly all of the available savings.

The practical reframing is to stop treating the registry as a strategic choice and start treating it as plumbing with two tunable knobs: where it sits relative to the runners, and how aggressively it is pruned. A team that turns both knobs gets fast cold jobs and a flat storage bill on the registry it already has, which is a better outcome than the migration it was tempted to run.

Recommendations

Cache image layers on the runner

Runner-side caching collapses a cold pull from tens of seconds to a few and cuts the egress those pulls would otherwise bill, regardless of which registry sits upstream. It is the single highest-leverage move in this report because it addresses both the latency and the egress lines at once, without a registry migration.

Place the registry in the same region as the runners

A cross-region pull roughly doubles the latency and bills cross-region egress on every layer. Keeping the registry in the same region as the runners removes the hop, halving the modeled pull time and trimming the egress line, again without changing which registry you use.

Treat the registry as a cache with a TTL, not an archive

Storage of dead tags is the largest line in the bill because the default behavior is append-only. Apply age-based retention, keep only the last N builds per branch, and schedule cleanup of untagged layers, which routinely cuts storage by a large fraction with no operational risk because the pruned tags were never pulled.

Choose the registry on governance and cost, not speed

Once caching neutralizes the latency difference, the major registries are interchangeable on performance. Pick the one your workloads and policy needs already point to: a cloud registry where workloads live in one cloud, GHCR for GitHub-centric teams, or Artifactory and Nexus where polyglot artifacts, access control, or air-gapping demand them.

Measure pull time and storage growth as standing metrics

Both costs are invisible per run and only show up in aggregate, so track median cold-job pull time and month-over-month storage growth the way you track build duration. When either drifts upward, the cause is almost always a cache miss, a cross-region placement, or retention that stopped pruning, all of which are quick to correct once seen.

Outlook

Expect the cloud-provider registries to keep consolidating share over the next two years, driven by the same gravity that produced today's split: as more workloads settle into a single cloud, keeping images in that cloud's registry to avoid egress and inherit its access model becomes the path of least resistance. The dedicated enterprise products will hold their niche on governance and polyglot breadth rather than win it back on features, because the feature gap that once justified them has largely closed.

The latency conversation will increasingly move off the registry and onto the runner. As runner-side caching becomes a standard expectation rather than an optimization, pull latency will stop being a registry-selection criterion at all, and teams will choose registries purely on governance and cost. The registries that thrive will be the ones that integrate cleanly with that caching layer rather than the ones that try to win on serving speed they no longer need to.

For most teams the durable takeaway is that the registry bill and the registry latency are both addressable without a migration, which is the opposite of how the decision usually feels. Cache on the runner, place same-region, prune aggressively, and the registry you already have will be fast and cheap. The teams that internalize that will stop running registry migrations they do not need and start turning the two knobs that actually matter.

Methodology

This report synthesizes publicly available developer and cloud-native survey data with Latchkey's own analysis of registry pull latency and runner economics across managed CI workloads. Registry adoption shares are modeled from public survey direction and typical deployment patterns, not a single primary survey, and indicate relative position rather than precise population values. Pull-time and cost-split figures are modeled for a mid-size image and a mid-size org and will vary with image size, layer reuse, region placement, and retention policy. Per-minute figures use the Latchkey managed rate of $0.0025 per minute from the shared pricing spine, roughly 70 percent below the hosted blend. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• CNCF Annual Survey
• GitHub - Octoverse
• GitHub Actions documentation
• AWS EC2 On-Demand pricing

More Latchkey reports