Microservices CI cost in 2026: when 50 repos cost 50x

Microservices spread CI across many repositories, each with its own pipeline. The simple multiplier is brutal: 50 services means 50 pipelines, each running on every push to each service. The per-service overhead alone (image pull, cache restore, framework setup) consumes 25-40% of compute. The structural fix is shared CI templates plus per-service caching plus a clear ownership model between platform and service teams. This page walks through the cost shape, the templates and ownership patterns that scale, and the realistic before-and-after numbers from teams that adopted them.

Where the multiplier comes from

A microservices CI bill scales as services x pushes x average_pipeline_minutes. Each multiplier compounds. Services grow as the architecture matures (10 to 30 to 80 services over time). Pushes per service grow as the team grows (each service gets more contributors). Average pipeline minutes grow as test suites mature.

Worse, much of the per-pipeline time is overhead unrelated to the service's actual work. A typical microservices pipeline spends 30-90 seconds pulling base images, 30-60 seconds restoring caches, 15-30 seconds initialising the test framework. Total setup overhead: 60-180 seconds per pipeline run. With 500 pipeline runs per day, setup overhead alone consumes 8-25 hours of compute daily, or 240-750 hours per month.

The setup overhead is structural, not per-service-specific. It is the same on every service. This is what makes shared infrastructure (cached base images, pre-warmed runners, common cache backends) so high-leverage in microservices CI: one infrastructure improvement reduces overhead across all N services simultaneously.

Reusable workflow templates

The most powerful organisational tool for microservices CI is the reusable workflow template. GitHub Actions reusable workflows let you define a workflow once and call it from many service repos. GitLab CI includes serve the same purpose. CircleCI orbs are the equivalent.

The template defines the structural pipeline: setup steps, common security scans, deploy hooks, notification rules. The service repo defines only what is service-specific: which test command, which artifacts to publish. A typical service-side workflow becomes 10-20 lines of YAML calling the template, instead of the 200-500 lines that would otherwise duplicate across N services.

The cost benefit is twofold. First, when you optimise the template (better caching, faster setup, removed redundant steps), every service benefits immediately. Second, when you add a new check (security scan, license compliance) you add it once in the template rather than 50 times in 50 service repos.

Template versioning: blast radius

A template that all services use becomes a critical-path system. A bad template change can break CI for every service in the organisation. Mitigation: explicit template versioning. Pin services to specific template versions (in GitHub Actions, uses: org/template-repo/.github/workflows/ci.yml@v1). Roll out template upgrades gradually: cut a v2, migrate one service first, watch for issues, then expand to all services over a week or two.

The platform team owns template SLO: any breaking change to a pinned version goes through change-control like any production system. Service teams have predictable behaviour from the template they pin to, with explicit upgrade pressure (security patches need to be adopted within a deadline) but no surprise breakage.

Shared cache backends

Each service's dependency cache lives separately by default. Each service's Docker layer cache lives separately. Aggregate cache storage grows with services x cache-size-per-service. With 50 services each having a 500MB cache, total CI cache storage is 25GB, which is well past the GitHub Actions 10GB per-repo limit.

The fix is a shared cache backend that lives outside the per-repo cache. S3 with appropriate bucket structure, ECR Pull Through Cache for container images, a shared Artifactory or Verdaccio for language packages. Each service draws from the shared cache, so the "first build pays cold cost" phenomenon happens once per dependency across the whole org rather than once per service.

Operational cost of running a shared cache: typically $50-200/month for the backing storage and any small operating service. Saving on CI compute: typically $300-1,000/month for a 50-service team. Strong payback at any meaningful scale.

Centralised vs federated CI ownership

Two organisational models for who owns CI in a microservices environment. Centralised: a platform-engineering team owns CI infrastructure, templates, runners, and cost optimisation. Service teams consume the templates and own only their service-specific pipeline content. Federated: each service team owns its own CI end-to-end, including infrastructure choices.

Centralised is structurally cheaper at scale because of the economies of shared infrastructure. The trade-off is service-team autonomy: a service team that wants to use a specific build tool or a specific test framework may be constrained by what the template supports. Federated is more flexible but consistently more expensive: each team reinvents caching, observability, and runner provisioning. Most engineering organisations of 100+ people land on centralised by force of cost discipline.

The hybrid pattern that works: centralised platform owns the structural pipeline and the runner pool; service teams own the test content and the deploy hooks. Service teams contribute back to templates when they need new functionality. Platform team holds the cost dashboard and the SLOs.

Cross-repo trigger costs

Sometimes services depend on each other in CI: a backend service's changes need to trigger an integration test in the API gateway service. Cross-repo triggers add cost because each linked CI run is real compute. Done well, this is a small line item; done poorly (every commit to service A triggers full integration suites in services B, C, D), it can dominate the bill.

The pattern that scales: contract tests rather than integration tests. Each service publishes its API contract; consumers run a contract test against the published contract, not against a live instance of the producing service. Pact and Spring Cloud Contract are the dominant tools. Contract tests are fast, do not require cross-repo orchestration at CI time, and catch the same incompatibilities that full integration tests catch (with some discipline about contract maintenance).

Frequently Asked Questions