Zhivko Todorov
ALL CASE STUDIES

CASE 70 · TAMARIND · 2025

BUILD CACHES3ECRCI

CI builds that finish before the engineer remembers they pushed.

A developer infrastructure company had CI pipelines averaging 14 minutes per build, dominated by dependency installation and container layer rebuilds. We added an S3-backed build cache for the dependency steps and ECR layer caching for the container builds. Median build time landed at 92 seconds.

INDUSTRY

Developer infrastructure

DOMAIN

PLATFORM

DELIVERED

2025

STACK

GITHUB ACTIONS·S3 (BUILD CACHE)·ECR (LAYER CACHE)·BUILDKIT·CLOUDFRONT (CACHE DELIVERY)

RESULTS

What changed, by the numbers.

MEDIAN BUILD TIME

92s

WAS 14m

CACHE HIT RATE

78%

AVERAGE ACROSS REPOS

DEVELOPER WAIT TIME

−87%

PER-PUSH AGGREGATE

CI COMPUTE BILL

−41%

FEWER MINUTES BURNED

HOW IT WENT

Builds had been slow because every build was a full build. Node modules reinstalled, Cargo registries refetched, Docker images rebuilt from scratch. We surveyed the actual cache miss patterns and discovered most variation came from lockfile changes — the rest of the dependency graph was stable for weeks at a time.

S3 became the durable cache for `node_modules`, Cargo target directories, and pip wheels, keyed on lockfile hashes. BuildKit pushed/pulled ECR layer caches per Dockerfile. CloudFront in front of S3 sped up the cache pulls for the regions where CI runners ran.

Median build time dropped from 14 minutes to 92 seconds. CI compute bill fell 41% — even with the S3 storage cost added, the math heavily favoured the cache. Engineers stopped complaining about builds in the team retro. They started noticing other things instead.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →