The 2026 Dependency Install Benchmark

A baseline for how long a clean install takes versus a cached one across npm, pip, maven, cargo, and composer, and how much of that time a warm cache gives back.

Executive summary

Installing dependencies is the quiet prologue on nearly every CI job, and on a cold runner it is rarely quiet. Before any test runs, the job resolves the dependency graph, downloads every package, and writes them to disk. On an ephemeral runner that work starts from nothing on each invocation, because the previous job's installed packages went away with the instance that held them. The install is not incidental setup; for many pipelines it is one of the largest single phases of the run, paid in full on every push.

Across the major package managers the cold install time varies by an order of magnitude, driven by how much each manager downloads, how hard its resolution is, and whether it compiles on the way in. But the pattern underneath the variation is the same everywhere: most of that time is recoverable with a warm cache, because most of it is spent re-fetching and re-resolving dependencies that did not change since the last run. The install is slow mostly because it keeps redoing settled work.

This benchmark times cold versus cached install for npm, pip, maven, cargo, and composer, then prices the recovered minutes against published runner rates. The managers differ in how much they gain from caching, but every one of them spends the majority of a cold install on work a warm cache makes free. The benchmark gives each manager a baseline so a team can see how much wall-clock a cache can return before any other tuning, and which manager's install is worth caching first.

A managed runner keeps that cache warm across ephemeral jobs and bills the residual install at the managed rate rather than the full hosted Linux price. This is the combination that matters: the cache turns a multi-minute cold install into a sub-minute warm restore, and the lower per-minute rate makes even the residual install cheaper than it would be on hosted. Because the install runs on essentially every job, both effects compound across a busy repository where CI runs on every push.

With CI adoption near 76 percent of professional developers, the install prologue is one of the most-repeated operations in the entire engineering workflow, paid on nearly every job across nearly every team. That ubiquity is what makes it a high-leverage target. A change that shaves the install does not help one pipeline once; it helps every pipeline on every push, which is why dependency caching is consistently one of the best ratios of payoff to effort in all of CI.

Cold install time spans an order of magnitude

The cold-install baselines are not close together. Cargo and maven carry the heaviest cold installs because they resolve large graphs and, in cargo's case, compile dependencies on the way in, while composer and pip are comparatively light. In our model the spread runs from about a minute and a half at the low end to over five minutes for cargo, an order-of-magnitude range across managers that all do nominally the same job of getting dependencies onto disk.

This spread matters because it sets how much a cache can possibly give back. A manager with a ninety-second cold install has at most ninety seconds to recover; a manager with a five-minute cold install has five minutes of potential savings on the table. Knowing your manager's baseline tells you the size of the prize before you do anything, and it tells you which pipelines will feel the biggest improvement from caching and which were never going to gain much.

It also reframes cross-language comparisons. A team should not conclude that one stack is simply slow because its install baseline is high; the install is a fixed cost of the manager, and the question is how much of it the team is leaving uncached. A heavy-install manager that caches well can end up faster in practice than a light-install manager that does not cache at all, which is exactly the kind of inversion the per-manager baselines make visible.

• Cold install runs from about 1.5 minutes (composer) to over 5 minutes (cargo) in the model.
• Cargo and maven are heaviest because they resolve large graphs and, for cargo, compile on install.
• The baseline sets the ceiling on how much wall-clock a cache can return for that manager.

Download and resolution dominate a cold install

When a cold install minute is decomposed, package download and dependency resolution together account for the clear majority of it, with disk write and linking a smaller slice and post-install scripts the smallest. The two dominant slices are exactly the work a warm cache skips: a cache that already holds the resolved package set turns both the fetch and much of the resolve into a restore rather than a recomputation.

This is why caching the resolved dependency set is the highest-leverage change available on the install, ahead of any micro-optimization to the install command's flags. The biggest slices are the ones a cache removes wholesale. Tuning the smaller slices, parallelizing post-install scripts or speeding the disk write, attacks the parts of the install that were never the problem, while leaving the download and resolution that actually dominate the minute untouched.

The decomposition also explains why the savings are so consistent across managers despite their different baselines. Every one of these managers spends the bulk of its cold install on download and resolution, so every one of them has the same large, cacheable majority. The managers differ in absolute size, but they share the property that most of the install is the cacheable part, which is what makes the percentage recovered so stable across the board.

• Package download and dependency resolution are the two largest slices of a cold install.
• Both are exactly the work a warm cache turns into a restore.
• Disk write, linking, and post-install scripts are the smaller, less cacheable remainder.

A warm cache removes most of the install everywhere

Across all five managers a warm cache recovers roughly four-fifths of cold install time, dropping multi-minute installs to well under a minute. The exact gain differs by manager, from about seventy-nine percent for npm and pip to eighty-two percent for cargo, but the striking result is how narrow that band is. The percentage recovered barely moves across managers with wildly different baselines, because they all share the same large cacheable majority of download and resolution.

The practical consequence is that no manager stays slow once its resolved dependencies are cached and restore quickly. Cargo's five-minute cold install, the worst case in the benchmark, drops to under a minute warm, landing in the same neighborhood as composer's already-light install. Caching does not just trim the heavy managers, it largely erases the differences between them, because it removes the part of the install where the differences lived.

This is also why the cached-install chart is the one that matters operationally. The cold baselines tell a team how slow the install can be; the cached baselines tell it how slow the install has to be once caching is in place, which is the number the team will actually live with on most runs. The gap between the two charts is the recoverable waste, and for every manager in the benchmark that gap is the majority of the cold install.

• A warm cache recovers about 79 to 82 percent of cold install time across all five managers.
• The percentage recovered is remarkably stable despite very different cold baselines.
• Caching narrows the gap between heavy and light managers by erasing their shared cacheable part.

The install is billed at the full hosted Linux rate

On GitHub-hosted Linux runners the install prologue is billed at the published per-minute Linux rate on every job, cached or not. The meter does not distinguish between minutes spent on useful test work and minutes spent re-downloading dependencies that have not changed since yesterday; every minute of the install is a billed minute at the same rate, including the large cacheable majority that a warm cache would have made free.

Because the install runs on essentially every job, this billing compounds far faster than its per-run size suggests. A single uncached install on a single job is a minor cost. The same uncached install repeated across every push from every contributor, on a repository where CI runs on every push, is a recurring charge for redoing settled work thousands of times a month. The install is small per run and large in aggregate, which is the classic shape of a cost worth attacking.

Two independent levers act on this charge, and they multiply. The cache reduces the number of billed install minutes by turning a cold install into a warm restore. A lower per-minute rate reduces the price of each remaining install minute. Applying both, a warm cache on a managed runner, shrinks both terms of the install bill at once, which is why the cheapest install is not merely a cached one but a cached one billed below the hosted Linux rate.

Managed runners keep the cache warm and cost less per minute

Ephemeral runners discard the cache with the instance, which is the root cause of the cold install repeating. The runner that did the expensive resolution and download is destroyed when its job finishes, so the next job starts from an empty disk and pays the full cold install again. The ephemerality that makes hosted runners clean and isolated is the same property that throws away the cache the team most wants to keep.

A managed runner resolves this tension by persisting the cache across jobs even as the runner environments themselves remain ephemeral. The dependency cache survives the instance, so the next job restores rather than re-downloads, keeping installs fast without giving up the clean, isolated per-job environment. The team gets the warm cache and the fresh runner, rather than having to choose one at the expense of the other.

On top of that, the managed runner bills the residual install minutes at the managed rate, well below the hosted Linux price, so even the part of the install that remains after caching costs less per minute. The two effects, a warm cache and a lower rate, are exactly the two levers from the billing finding, delivered together. That is why a managed runner is the natural endpoint of the install-optimization argument: it shrinks both the minutes and the price of the prologue that every job pays, with Latchkey landing roughly 70 percent below hosted on the rate.

Cache correctness decides whether the savings appear

The four-fifths of install time a warm cache recovers is a ceiling, not a guarantee. It materializes only when the cache actually hits, and a cache that hits inconsistently delivers a fraction of its modeled benefit while still adding complexity to the pipeline. The single biggest determinant of whether a team realizes the benchmark's savings is not whether it has a cache but whether its cache keys are correct.

The failure modes sit on either side of a narrow target. A key scoped too loosely, ignoring the lockfile, serves stale dependencies that no longer match what the project declares, which produces subtle, maddening build failures that are worse than no cache at all. A key scoped too tightly, including volatile inputs that change every run, almost never hits, so the cache exists on paper while every job quietly pays the full cold install. Both look like a working cache from a distance.

The discipline that gets the savings is to scope cache keys to exactly the inputs that determine the resolved dependency set, the lockfile and the toolchain version, and then to monitor the hit rate as a first-class metric. A cache nobody measures is a cache that silently degrades, and the install creeps back toward its cold baseline without anyone noticing, because the failure is invisible on the invoice until someone goes looking for it.

• The modeled savings appear only on a cache hit; a low hit rate quietly forfeits most of them.
• Keys scoped too loosely serve stale dependencies; keys scoped too tightly almost never hit.
• Scope keys to the lockfile and toolchain version, and monitor hit rate like test coverage.

The install is the same cost on every job, so it compounds

Unlike test work, which varies with what a change touches, the dependency install is largely fixed per job. A one-line change and a thousand-line change pay roughly the same install, because both resolve and fetch the same dependency graph before either runs a test. That uniformity makes the install a flat tax on every job, independent of the size or value of the change being validated.

A flat per-job cost compounds aggressively on a high-frequency trigger. Because pull-request checks run on every push and dominate CI volume, an uncached install is paid over and over for changes that touched no dependencies at all. The install is the part of the run least related to what changed, yet on an ephemeral cold fleet it is paid in full every single time, which is precisely the profile of waste that caching exists to remove.

This is why the install repays optimization out of proportion to its per-run size. Shaving a minute off a once-a-day nightly job saves a minute a day; shaving the same minute off an install that runs on every push across a busy repository saves that minute thousands of times a month. The benchmark frames the install as a high-frequency, low-variance cost, which is the exact shape of cost where a cache and a lower per-minute rate pay back fastest.

Recommendations

Know your manager baseline before tuning anything

Cold install ranges from about ninety seconds to over five minutes across managers, and that baseline sets the ceiling on what a cache can return. Measure your own cold install first so you know the size of the prize, and prioritize caching the heaviest-install pipelines, where the recoverable wall-clock is largest.

Cache the resolved dependency set, not the install flags

Download and resolution are the two dominant slices of a cold install and exactly what a warm cache skips. Caching the resolved package set is far higher leverage than micro-tuning the install command, which only touches the smaller disk-write and post-install slices that were never the problem.

Key the cache to the lockfile and toolchain version

A warm cache recovers around four-fifths of install time only when it actually hits. Scope cache keys to the lockfile and toolchain version so the cache is neither too loose (serving stale dependencies) nor too tight (almost never hitting), and measure the hit rate the way you measure test coverage.

Treat the install as a per-job recurring charge

The install is billed at the full hosted Linux rate on every job, cached or not, so its small per-run cost compounds across every push on a busy repository. Optimizing it is high leverage precisely because it runs on nearly every job, which is what turns a minor per-run saving into a large aggregate one.

Use a managed runner to keep the cache warm and the rate low

Ephemeral runners discard the cache with the instance, so the next job pays the cold install again. A managed runner persists the cache across ephemeral jobs and bills the residual install at roughly 70 percent below the hosted Linux rate, shrinking both the install minutes and the price of each one at the same time.

Outlook

Expect dependency caching to move from an advanced practice to an assumed default through 2026, the way CI itself did. The benchmark shows the gain is large, around four-fifths of cold install time, and remarkably consistent across managers, which makes the case hard to argue with once a team measures its own cold baseline. The teams still paying full cold installs on every push will increasingly look like the outliers rather than the norm.

Cache correctness, not cache existence, is where the next round of attention will go. The recovered four-fifths only materializes when the cache actually hits, and a cache keyed too loosely or too tightly quietly stops paying off. We expect hit-rate monitoring to become standard practice, because a cache nobody measures is a cache that silently degrades, and the install slowly creeps back toward its cold baseline without anyone noticing on the invoice.

The durable conclusion is that the cheapest install is both cached and cheaply billed, and that a managed runner is the natural way to get both at once. Persisting the cache across ephemeral jobs removes the structural reason the cold install repeats, and billing the residual minutes below the hosted rate compounds the saving on the most-repeated operation in CI. Over the next two years we expect the warm, managed install to become the baseline that teams measure themselves against.

Methodology

This benchmark models cold and cached dependency install time for npm, pip, maven, cargo, and composer on typical project graphs, and prices the recovered minutes against published GitHub Actions runner rates. Install times, the percentage recovered, and the cold-install minute split are Latchkey modeled estimates labeled as such; per-minute pricing ties to the published GitHub-hosted Linux rate ($0.008/min) and the Latchkey managed rate ($0.0025/min, a 70% reduction versus the blended hosted average). CI adoption near 76% frames how often the install prologue is paid. 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 - Octoverse
• GitHub Actions - billing & pricing
• GitHub Actions documentation
• JetBrains Developer Ecosystem Survey

More Latchkey reports