The State of CI/CD Artifacts 2026

Build artifacts keep getting bigger and living longer: this is what that storage and transfer actually cost, and how much of it is paid for outputs no one ever fetches again.

Executive summary

Artifacts are the outputs a pipeline hands off: build outputs, test reports, coverage data, container images, debug symbols, and the caches that speed the next run. They are easy to ignore because no single upload feels expensive, but they accumulate relentlessly. Artifact sizes have grown as builds bundle more, and default retention windows keep every one of them around far longer than anyone actually needs. The result is a line item that grows quietly with build count and almost never gets audited.

The cost is two-sided. There is storage, paid for every artifact across its full retention window whether or not it is ever touched again, and there is transfer, paid every time an artifact is uploaded or downloaded across jobs and runners. Most of that storage is for artifacts that are never fetched again after the build that produced them, which means the dominant cost driver is not the artifacts teams use but the ones they forgot to expire.

This report quantifies artifact size growth, what storage and transfer cost over a typical retention window, and why retention policy and cache hygiene are the cheapest line-item wins in CI. Unlike most optimizations, these require no change to the build, the tests, or the application: they are configuration. Shortening a retention window and co-locating a cache are the kind of changes a single engineer can make in an afternoon and watch land on the next invoice.

The reason this spend hides so well is that it is diffuse. A 540 megabyte container image stored for 90 days is not an alarming number on its own, but multiplied by every run across every monitored repo and held for a quarter, the long tail of never-fetched outputs becomes the largest single component of the artifact bill. No one upload is worth investigating, so the aggregate never gets investigated, and it compounds.

The throughline for 2026 is that artifact cost is governed by two multipliers most teams leave at their defaults: retention length and reuse pattern. Storage is size times retention; transfer is size times how often the artifact moves. Pull both multipliers down, by expiring transient outputs fast and keeping reused artifacts on a fast co-located cache, and the artifact bill stops tracking build count and starts tracking only what teams actually use.

Most stored artifacts are never fetched again

The dominant share of artifact storage volume is build outputs that are uploaded, kept for the full default retention window, and never downloaded after the run that produced them. They exist only because the default retention is long and nobody changed it. The retention chart makes the proportion stark: the never-downloaded-again slice is larger than every other category combined, which means most of the artifact bill buys storage for outputs no one ever reads.

This is a different shape of waste than most CI inefficiency, and it is cheaper to fix. There is no tradeoff to weigh, no coverage to lose, no build to slow down. The never-fetched outputs are pure dead weight: shortening their retention to match how they are actually used removes the cost with no performance penalty whatsoever. It is the rare optimization where the only obstacle is that nobody looked.

Shortening retention to match actual use is therefore the single cheapest CI cost cut available. The artifacts that genuinely matter, release builds and outputs fetched by later jobs, are a small minority that can be kept as long as needed. Everything else, the transient build scratch that the donut shows dominating storage, can expire in days. The discipline is simply to stop treating every artifact as worth keeping for a quarter.

• Never-downloaded-again outputs are the single largest slice of stored artifact volume, larger than all reused categories combined.
• Shortening their retention carries no performance penalty, because nothing ever reads them.
• The artifacts worth keeping (releases, later-job inputs) are a small, easily-identified minority.

Retention default is the silent multiplier

GitHub Actions retains artifacts for 90 days by default, and most teams never shorten it, so every transient build output sits in storage for three months whether or not it is ever touched again. Retention is a multiplier on storage cost, and leaving it at the default means paying the maximum on every artifact regardless of how briefly it is useful. The default is conservative by design; the cost of that conservatism is rarely examined.

Cutting retention to the window teams actually need, often two weeks or less for non-release artifacts, collapses storage cost by a large multiple. The cost chart shows the effect directly: the same repo's monthly artifact bill drops sharply moving from 90-day to 14-day retention, because storage cost scales linearly with the retention window and most artifacts have no value past their build. The shorter window does not lose anything anyone uses; it stops paying for the long tail of the unused.

Per-artifact retention overrides are what make this safe rather than a blunt instrument. Release artifacts and published builds can carry a long retention while build scratch and intermediate outputs expire fast, so the policy matches the value of each artifact type rather than applying one window to everything. The team keeps what it needs for as long as it needs it and stops paying for the rest, which is exactly the granularity the default flat 90 days denies.

Transfer is a real cost, not a rounding error

Beyond storage, artifacts cost transfer every time they move between jobs, runners, and the cache. For pipelines that fan a large artifact out across many parallel jobs, that transfer is paid on every job, every run, and it adds up fast. The transfer chart shows cross-job transfer and cache up/download together rivaling long-tail storage as a cost driver, which surprises teams that assumed storage was the whole story.

Transfer also has a wall-clock cost that the dollar figure understates. Every megabyte a job uploads or downloads is time the job spends waiting on the network rather than doing useful work, so a transfer-heavy pipeline is both more expensive and slower. The cost shows up twice: once on the storage-and-transfer bill and again on the runner-minute bill, because the jobs run longer while they move data around.

Keeping artifacts on a fast, co-located cache instead of round-tripping them through distant storage cuts both the bill and the wall-clock. When the artifact lives next to the runners that need it, a cross-job handoff is a local fetch rather than a trip across a region boundary, and the transfer cost largely disappears. This is where co-location pays off twice over, and it is a property of the runner layer rather than anything the build has to change.

Cache misses re-pay the transfer cost every run

A cold or evicted cache turns every run into a full re-download of dependencies and base layers, which is artifact transfer paid over and over. Each miss is not just a slow build, it is a repeated transfer cost that a warm cache would have amortized to nearly nothing. The teams with the highest artifact transfer bills are very often the teams with the lowest cache hit rates, paying the same download again on every single run.

A reliable, co-located cache is what keeps that cost amortized across runs. The first run pays the transfer to populate the cache; every subsequent run that hits it pays essentially nothing. The economics only work if the cache actually hits, which is why cache hit rate and artifact transfer cost are tightly coupled: a cache that misses half the time is re-paying the transfer on half the runs, and the saving the cache was supposed to deliver never materializes.

On managed runners with a fast cache layer, repeated transfer collapses into a single warm fetch, which is where much of the artifact saving actually comes from. The cache is co-located with the runners and reliable enough to hit consistently, so the expensive cold transfer happens once rather than on every run. Artifact cost and cache reliability are the same problem viewed from two angles, and a runner layer that gets the cache right gets the transfer bill right at the same time.

• A cold or evicted cache re-downloads dependencies and base layers on every run, re-paying transfer indefinitely.
• Cache hit rate and artifact transfer cost are tightly coupled: a low hit rate means repeated cold transfers.
• A co-located, reliable cache amortizes the cold transfer to a single warm fetch.

Artifact sizes are growing, which raises the stakes on both multipliers

Median build-artifact size has grown roughly 1.9 times over the past two years as builds bundle more: richer container images, larger web bundles, more debug symbols, and fatter mobile binaries. The size chart shows the spread across pipeline types, with container and binary artifacts dwarfing library packages by an order of magnitude. As the base size rises, every multiplier that acts on it, retention and reuse alike, costs more in absolute terms.

This growth is why artifact cost is becoming a line item teams notice rather than ignore. When artifacts were small, a long retention window and a few cross-job transfers were genuinely negligible, and the instinct to leave the defaults alone was harmless. At today's sizes, the same defaults applied to a 540 megabyte image or a 920 megabyte binary produce a bill worth auditing, and the gap between a tuned and an untuned policy widens with every increment in artifact size.

The practical implication is that the two multipliers, retention length and reuse pattern, matter more every year. A team that leaves retention at 90 days and lets a cold cache re-transfer fat artifacts on every run is paying a tax that grows with their artifact sizes whether they notice it or not. Tuning both is not a one-time cleanup so much as a policy that keeps the bill flat while the artifacts themselves keep getting bigger.

Managed runners cut the storage-and-transfer bill from both sides

Because artifact cost is storage times retention plus transfer times reuse, it compounds quietly with every run. Each new build adds a little storage and a little transfer, and across a quarter and a fleet of repos that little-by-little accumulates into the largest unaudited component of many CI bills. The compounding is what makes it dangerous: nothing about any single run looks expensive, so the growth never triggers a review.

Managed runners model near 70 percent lower runner cost than hosted, and a co-located cache plus sane retention attack the artifact bill from both sides: less long-tail storage and far less repeated transfer. The runner-cost saving and the artifact saving stack, because the same infrastructure that runs the jobs more cheaply also keeps the cache warm and co-located so the transfer largely disappears. The cost chart shows the managed line sitting below even an aggressively shortened hosted retention.

For repos with heavy container or binary artifacts, that combination is the difference between an artifact bill that grows with build count and one that stays flat. The long-tail storage is expired by policy, the cross-job transfer collapses into local fetches, and the cold-cache re-transfer becomes a single warm fetch. What remains is the cost of the artifacts teams actually use, which scales with usage rather than with the raw number of builds the pipeline happens to run.

Artifact hygiene is the cheapest CI cleanup nobody schedules

Of all the optimizations in CI, artifact hygiene has perhaps the best ratio of payoff to effort, and it is the one teams most consistently never get around to. Shortening retention and co-locating a cache are configuration changes a single engineer can make in an afternoon, with no risk to the build and no coverage to lose. The only reason they go undone is that artifact cost is diffuse enough to never become anyone's priority.

The contrast with harder CI work is instructive. Speeding up a slow test suite or untangling a flaky integration test is real engineering effort with real risk. Setting a 14-day retention on build scratch and pointing the cache at co-located storage is neither, yet it can take a larger bite out of the bill than weeks of test optimization, because it removes a cost that scales with every run rather than trimming the duration of one.

The discipline that captures this is small: audit what retention each artifact type actually needs, expire the transient outputs fast, keep releases long, and put the reused artifacts on a fast co-located cache. Teams that do this once and encode it in their pipeline template never think about artifact cost again, because the policy keeps the bill tracking usage rather than build count. Teams that never do it watch the long tail compound quarter after quarter, paying for storage and transfer on outputs no one will ever read.

Recommendations

Shorten retention to match how artifacts are actually used

The 90-day default keeps every transient build output for a quarter whether or not it is ever fetched. Cut non-release retention to two weeks or less, the window teams actually need, and storage cost collapses by a large multiple with no performance penalty, because the never-downloaded-again outputs are pure dead weight.

Use per-artifact retention overrides

Do not apply one window to everything. Keep release and published artifacts long while build scratch and intermediate outputs expire fast, so the policy matches the value of each artifact type. This is what makes a short default safe rather than a blunt instrument that risks expiring something you need.

Co-locate the cache to kill cross-job transfer

Cross-job transfer and cache up/download together rival storage as a cost driver, and they cost wall-clock as well as dollars. Keep artifacts on a fast cache co-located with the runners so a handoff is a local fetch rather than a trip across a region boundary, and the transfer cost largely disappears from both the bill and the build duration.

Raise cache hit rate so cold transfers stop recurring

A cold or evicted cache re-downloads dependencies and base layers on every run, re-paying transfer indefinitely. Tune the cache for a high hit rate so the expensive cold transfer happens once and every subsequent run pays a warm fetch. Cache reliability and artifact transfer cost are the same problem viewed from two angles.

Move steady-state CI to managed runners

Managed runners model near 70 percent lower runner cost than hosted and pair a co-located cache with sane retention to attack the artifact bill from both sides. For repos with heavy container or binary artifacts, that combination keeps the bill tracking usage rather than build count, which matters more every year as artifact sizes keep growing.

Outlook

Expect artifact cost to keep rising on teams that leave their defaults alone, simply because artifacts keep getting bigger. Median artifact size has already grown roughly 1.9 times in two years, and richer images, larger bundles, and fatter binaries show no sign of reversing. The same untouched 90-day retention and cold-cache transfer that were negligible at small sizes become a bill worth auditing at today's, and the gap widens every year.

The architectural direction is toward runner layers that handle artifact economics by default: co-located caches that keep transfer local, sensible retention baked into the pipeline template, and per-artifact policies that keep releases long while scratch expires fast. As that becomes the default rather than a configuration achievement, the teams on managed infrastructure will keep their artifact bills flat while teams on untuned hosted defaults watch theirs track build count upward.

For most teams the practical takeaway is that artifact cost is the cheapest line item in CI to fix and the one most consistently left undone. It needs no build change and no coverage tradeoff, only a retention audit and a co-located cache. The teams that schedule that afternoon of cleanup, and encode it in their pipeline template so it stays done, stop paying for storage and transfer on outputs no one will ever read.

Methodology

This report synthesizes publicly available industry data (GitHub Actions artifact and retention documentation, published cloud storage and transfer pricing) with Latchkey's own analysis of artifact economics. Size-growth multiples, monthly costs, and the storage-and-transfer splits are modeled estimates derived from typical pipeline shapes and published storage and runner pricing (managed runner at $0.0025/min, roughly 70 percent below hosted), not a primary survey. Artifact sizes are expressed in megabytes. 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

• GitHub Actions documentation
• GitHub Actions - billing & pricing
• AWS EC2 On-Demand pricing
• GitHub - Octoverse

More Latchkey reports