The State of CI/CD for Agencies 2026

Agencies do not have one pipeline, they have dozens: this is how the long tail of per-client CI maintenance quietly eats the margin, and what converts it into leverage.

Executive summary

Agencies do not have one pipeline, they have dozens, one per client, each slightly different and most of them small. The challenge is not the raw scale of compute, it is the long tail: many repositories that each run a little CI, drift apart over time, and collectively consume more maintenance attention than any single client justifies. CI is universal in agency work, but the economics are governed by sprawl, not by peak load, and that distinction changes which optimizations actually matter.

The data shows two distinct costs, and they are different in kind. The first is direct compute spread thinly across many client accounts, which is hard to attribute and easy to leak, because no single client's CI is large enough to notice. The second, and larger, cost is the engineering time spent keeping non-identical pipelines alive: bumping actions, fixing flakes, and re-deriving the same setup for each new engagement. The compute is the visible cost; the maintenance is the one that eats the margin.

Agencies that templatize pipelines and centralize the runner layer convert that long tail from a liability into leverage. When every client inherits the same reusable workflow, a fix made once propagates everywhere, and the marginal cost of the next client's pipeline collapses toward zero. The alternative, a bespoke or copied setup per engagement, guarantees drift and turns every upgrade into N separate manual edits across a portfolio no one person can hold in their head.

Per-client attribution is the other half of the agency CI problem, and it is where margin silently leaks on fixed-price work. CI spread across many client accounts is genuinely hard to track, and a repo in a launch crunch can quietly cost an order of magnitude more than a dormant retainer. Without attribution, that cost never makes it onto an invoice, so the agency absorbs it, and the work that looked profitable on the proposal turns out not to be once the unbilled CI is counted.

This report quantifies the agency CI tail, shows where per-client cost actually accrues, and explains why a shared, templated pipeline on managed runners with clean per-client attribution beats bespoke setups repeated N times. The throughline is that agency CI is an operations problem disguised as a compute problem: the levers that matter are the ones that reduce the number of distinct things to maintain and make every client's usage visible, not the ones that shave a few cents off a minute.

The cost is the long tail, not the peak

Agencies rarely have a single expensive pipeline; they have many cheap ones that collectively cost a lot to keep running. Each client repo adds a little compute and a lot of attention, and it is the attention, not the compute, that dominates. The maintenance-split chart shows that more than a third of platform time goes to maintaining existing pipelines, with another large slice consumed by onboarding new client repos, before anyone builds anything new.

The structural reason is that maintenance scales with the number of repos rather than with any one client's activity. A dormant retainer repo still needs its actions bumped, its flaky build investigated, and its drifted config reconciled, even though it produces almost no compute. So the cost driver is the count of distinct pipelines a small platform team has to hold in their heads, and that count grows with every engagement regardless of how active each client is.

This is what makes agency CI economics different from a product company's. A product team optimizes a few pipelines that each run a lot; an agency optimizes a lot of pipelines that each run a little, and the levers that help the first barely touch the second. Shaving minutes off a busy pipeline is the wrong target when the real cost is the engineering time spent keeping two dozen non-identical pipelines alive. The long tail, not the peak, is the line item that eats the margin.

• Maintenance and onboarding consume the majority of platform time, before any new capability is built.
• The cost scales with the number of distinct pipelines, not with any single client's compute.
• A dormant retainer repo still costs attention even when it costs almost no compute.

Templated pipelines turn the tail into leverage

When every client repo inherits the same reusable workflow, a fix or upgrade made once propagates everywhere. That single property changes the economics of the whole portfolio: the marginal cost of maintaining the next client's pipeline drops toward zero, because there is no separate pipeline to maintain, only an instance of the shared one. The long tail stops being N things to fix and becomes one thing to fix N times over by inheritance.

The alternative, copying a past client's setup and editing it, looks fast per engagement but guarantees drift. The setup-time chart shows copying a past client roughly halves the hours of a bespoke build, which is why teams do it, but every copy is a fork that must thereafter be patched by hand. Multiply that across dozens of clients and an action bump or a security fix becomes a multi-day campaign of nearly-identical edits, each a chance to miss a repo or introduce an inconsistency.

Centralizing the pipeline definition is the single highest-leverage move an agency platform team can make, and the setup-time chart shows why: a templated pipeline on a managed runner drops new-client setup to about an hour, an order of magnitude below bespoke. The first client funds the template; every client after that is nearly free to onboard and free to maintain, because the maintenance happens once in the shared definition rather than N times across forks.

• A shared reusable workflow means a fix made once propagates to every client repo at no marginal cost.
• Copying a past client looks fast but creates a fork that must be patched by hand forever after.
• Templated plus managed runner drops new-client setup to about an hour, an order of magnitude below bespoke.

Per-client cost attribution prevents silent margin leak

CI spread across many client accounts is easy to lose track of, and that opacity is where margin quietly disappears. The cost-attribution chart shows the spread is enormous: a repo in a launch crunch can cost an order of magnitude more than a dormant retainer, and on fixed-price work that variance is absorbed entirely by the agency unless the cost is attributed and billed. The client paying a flat fee has no incentive to economize, and the agency has no visibility to notice.

Without per-client attribution, the launch-crunch cost never makes it onto the invoice, and the engagement that looked profitable on the proposal turns out thinner once the unbilled CI is counted. The leak is silent precisely because no single client's CI is large enough to trigger a review; it is the aggregate, spread across many accounts and many months, that adds up to real money the agency simply ate. Attribution is what turns that invisible aggregate into a line someone can see.

A managed runner layer that tags usage per client turns CI from an unbillable overhead into a transparent, attributable line. Once each minute is labeled with the client that consumed it, the agency can bill time-and-materials clients accurately, flag fixed-price clients whose CI usage is out of line with the contract, and make pricing decisions on the next engagement with real data. That visibility protects margin on fixed-price work in a way no per-minute discount can, because the problem was never the price of a minute, it was not knowing whose minute it was.

Flaky builds are an agency tax multiplied by N

A single flaky pipeline is an annoyance; the same flake replicated across twenty client repos is a recurring drain on a small platform team. The flaky-or-stale-build slice of the maintenance split is large for exactly this reason: every client's pipeline can fail transiently, and a team supporting two dozen of them is fielding mechanical failures across the whole portfolio, none of which reflect a real bug in anyone's code.

Most CI flakes are transient infrastructure failures: network blips, registry timeouts, and out-of-memory kills that pass on a clean retry. The test code is fine; the environment hiccuped. For a product team that is a manageable nuisance on a few pipelines, but for an agency it is the same nuisance multiplied by the number of clients, and every spurious red build pulls a platform engineer away from billable work to investigate a failure that was never real.

Self-healing runners that automatically recover transient failures remove the tax across the whole portfolio without anyone touching individual client test suites. When a step fails on a known-transient signal and the platform retries it on a fresh environment before a human sees it, the flake never reaches the client repo and never pulls an engineer off task. For an agency, that portfolio-wide recovery is worth far more than it is for a single-product team, because the tax it removes scales with the number of clients rather than with the activity of any one.

Managed runners fit the agency model better than self-hosting

Self-hosting runners assumes a stable, dedicated workload to amortize the fleet, the steady, predictable load of a single product that keeps the instances busy enough to justify owning them. Agency work is the opposite of that assumption: spiky, per-client, and short-lived per engagement, with load that surges during a client's launch crunch and falls to nearly nothing on a retainer. A self-hosted fleet sized for that pattern is either idle most of the time or starving jobs during the surges.

Managed runners match the agency shape because they bill only for what each client uses, with no idle fleet to carry between engagements. The runner-cost chart shows the per-minute economics, with the managed rate well below hosted across every OS, but for an agency the bigger win is the elasticity: a client in launch crunch gets the capacity it needs and a dormant retainer costs almost nothing, with no fleet sized for a peak that only one client hits at a time.

Managed runners capture roughly 69 percent of the compute savings versus hosted runners and remove the per-client ops burden entirely, which is exactly the burden agencies cannot spread across one big team. A product company can dedicate a platform group to patching and scaling a fleet; an agency's platform capacity is already consumed by maintaining the long tail of client pipelines. Removing the fleet operations entirely gives that scarce capacity back to the work clients actually pay for.

Onboarding speed compounds across a growing client base

For an agency, the time to stand up CI for a new client is not a one-time cost, it is a cost paid on every engagement, and engagements are the business. The setup-time chart shows the gap between bespoke and templated onboarding is roughly fourteen hours versus one, and across a steady flow of new clients that gap is a recurring tax on every win. An agency that onboards slowly is spending its scarcest resource, platform engineering time, on setup it could have inherited.

Onboarding speed also shapes what kinds of engagements an agency can take profitably. When standing up a client's pipeline costs the better part of two days, small or short engagements are marginal, because the setup overhead swamps the work. When it costs an hour, the same small engagements become viable, which widens the range of profitable work and lets the agency say yes to clients that a bespoke-setup shop would have to decline or underservice.

Templated onboarding on a managed runner is what makes fast onboarding sustainable rather than a heroic effort. The template encodes the agency's standard pipeline once, the managed runner removes the per-client fleet setup, and a new client inherits a working, attributable, self-healing pipeline in about an hour. That speed compounds across a growing client base in a way a product company never experiences, because for the agency the next onboarding is always coming, and the time it takes is a direct input to margin.

The agency advantage is fewer distinct things to maintain

Read together, every finding in this report points at one lever: reduce the number of distinct things the platform team has to maintain. The long-tail cost, the drift from copied setups, the unattributed spend, the multiplied flake tax, and the per-client ops burden are all consequences of a portfolio of non-identical pipelines on non-shared infrastructure. Collapse that into one templated pipeline on one managed runner layer and every one of those costs shrinks at once.

This is why the agency CI problem is an operations problem rather than a compute problem, and why the standard cost-cutting advice only partly applies. Caching and the Linux shift still help each client's pipeline, but the dominant agency cost is the maintenance attention that scales with the count of distinct setups. The highest-leverage move is not making each pipeline cheaper to run, it is making them all the same pipeline so there is only one thing to keep healthy.

The agencies that internalize this stop treating each client as a fresh CI project and start treating their portfolio as a single platform with many tenants. One template, one managed runner layer, per-client attribution, and self-healing across the whole fleet turn the long tail from the thing that eats the margin into the thing that scales the business, because adding the next client costs an hour of onboarding rather than a permanent addition to the maintenance burden.

Recommendations

Centralize on one templated, reusable pipeline

A shared reusable workflow means a fix or upgrade made once propagates to every client repo at no marginal cost. Resist the instinct to copy a past client and edit, which looks fast but creates a fork that must be patched by hand forever. Templating drops new-client setup to about an hour and turns the maintenance tail from N things to fix into one.

Attribute CI cost per client

A launch-crunch repo can cost an order of magnitude more than a dormant retainer, and without attribution that cost never reaches an invoice. Use a runner layer that tags usage per client so you can bill time-and-materials accurately, flag fixed-price clients whose usage exceeds the contract, and price the next engagement on real data. The leak was never the per-minute price, it was not knowing whose minute it was.

Auto-heal transient failures across the whole portfolio

A flake replicated across twenty client repos is a recurring drain on a small platform team, and most flakes are transient infrastructure failures that pass on a clean retry. Self-healing runners that recover those failures before a human sees them remove the tax across every client at once, without touching any individual client's test suite.

Move client CI to managed runners

Agency load is spiky, per-client, and short-lived, which is the opposite of the stable workload self-hosting assumes. Managed runners bill only for what each client uses, capture roughly 69 percent of the compute saving versus hosted, and remove the per-client ops burden that agencies cannot spread across one big team. A client in launch crunch scales up and a retainer costs almost nothing, with no idle fleet to carry.

Treat the portfolio as one multi-tenant platform

Stop treating each client as a fresh CI project. One template, one managed runner layer, per-client attribution, and portfolio-wide self-healing turn the long tail from the thing that eats the margin into the thing that scales the business, because the next client costs an hour of onboarding rather than a permanent addition to the maintenance burden.

Outlook

Expect the gap between templated and bespoke agencies to widen through 2026, because the cost of sprawl compounds with every client won. An agency that centralizes its pipeline and runner layer onboards faster, maintains less, and attributes cleanly, which lets it take on more clients without growing its platform team in proportion. An agency still copying and editing per-client setups feels the opposite: every new client adds permanently to a maintenance tail that a small team cannot keep pace with.

The architectural direction for agencies is toward the multi-tenant platform model, where the portfolio is a single templated pipeline on a managed, attributing, self-healing runner layer rather than a collection of bespoke setups. As managed runners make per-client attribution and portfolio-wide self-healing turnkey, the operational advantages that once required a dedicated platform team become available to small pods, which is precisely the scale most agencies operate at.

For most agencies the practical takeaway is that CI is an operations problem wearing a compute costume. The money is not in shaving cents off a minute, it is in reducing the number of distinct things to maintain and making every client's usage visible. Template the pipeline, centralize the runner layer, attribute the cost, and auto-heal the flakes, and the long tail of client repos stops eating the margin and starts being the leverage that lets the business scale.

Methodology

This report synthesizes publicly available industry data (developer surveys, the DORA State of DevOps research, published cloud and CI runner pricing) with Latchkey's own analysis of multi-client CI/CD runner economics. Agency-specific figures (repos per pod, the platform-time split, per-client setup hours, and per-repo monthly spend) are Latchkey modeled estimates derived from public pricing and typical agency repo portfolios (managed runner at $0.0025/min, roughly 69 percent below hosted), not a primary survey of named agencies, and are labeled as such. Adoption reflects the published Stack Overflow Developer Survey. 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

• Stack Overflow Developer Survey
• GitHub - Octoverse
• GitHub Actions - billing & pricing
• GitHub Actions documentation

More Latchkey reports