Decarbonizing software supply chains: practical steps

CI/CD pipeline carbon footprint varies enormously by technology stack, team size, and cloud provider carbon intensity. A rough benchmark: a medium-sized engineering team (50 engineers) running 500 CI jobs per day, each consuming 4 minutes of compute on a 2-vCPU runner, uses approximately 2,700 vCPU-hours per month. On AWS US-East-1 (grid carbon intensity ~0.35 kgCO₂/kWh) and assuming ~0.2W per vCPU, this is roughly 190 kgCO₂/month — comparable to driving a petrol car 800km. At scale (thousands of engineers), CI emissions become material in corporate Scope 2 reporting. The Green Software Foundation's Impact Framework can be used to calculate your specific pipeline's SCI.

Carbon-aware software is software that adjusts its behaviour based on the current carbon intensity of the electricity grid — running more work when renewable energy is abundant and less when the grid is carbon-intensive. Implementation approaches: use the Carbon Aware SDK (Linux Foundation) to access real-time and forecast carbon intensity data from Electricity Maps or WattTime; schedule batch jobs (nightly builds, ML training, data processing) for times and regions with lower carbon intensity; implement carbon-aware autoscaling that increases capacity during low-carbon periods and scales down during high-carbon periods; and use carbon intensity as a dimension in cloud region selection for deployable workloads.

Build caching saves energy proportional to the percentage of CI job time eliminated by cache hits. In well-tuned pipelines: Docker layer caching reduces image build time by 60–80% when base layers are stable; Gradle/Maven build caching with remote build cache eliminates 40–70% of compilation work for unchanged code; NPM/yarn package caching eliminates the 1–3 minute dependency download and install phase for most builds; and Bazel remote caching can achieve 80%+ cache hit rates for large monorepos. Combined, aggressive caching on a large CI platform can reduce total compute consumption by 50–70% — with direct proportional reduction in energy and carbon.

Distroless container images (developed by Google) contain only the application runtime and its direct dependencies — no shell, no package manager, no OS utilities, no system libraries beyond what the application requires. A typical Node.js distroless image is 50–100MB versus 150–300MB for a Node.js Ubuntu-based image. Smaller images reduce: registry storage energy; bandwidth energy for image pulls (multiplied by every container start across all nodes); and attack surface. The energy savings are small per individual container pull but significant at cloud scale where millions of container starts per day are common. Distroless also improves security by eliminating unnecessary software that could be exploited.

The Software Carbon Intensity (SCI) specification, published by the Green Software Foundation as an ISO standard (ISO/IEC 21031), defines a standardised metric for measuring the carbon intensity of software per functional unit — for example, per API request, per user session, or per transaction. The formula SCI = (E × I) + M / R calculates: energy consumed (E) times the carbon intensity of that energy (I in gCO₂e/kWh), plus the embodied carbon allocated to the software's hardware use (M), divided by the functional unit (R). SCI enables meaningful comparison of software carbon efficiency across versions, architectures, and deployments — making it possible to track improvement as software supply chain optimisations are implemented.

Cloud region carbon intensity varies significantly based on the local electricity grid's generation mix. Generally low-carbon regions include: AWS us-west-2 (Oregon) — predominantly hydroelectric and wind; GCP us-central1 (Iowa) — high wind energy percentage; Azure westeurope (Netherlands) — high renewable mix; AWS eu-west-1 (Ireland) — high wind energy; and GCP europe-west6 (Zürich) — largely nuclear and hydro. High-carbon regions include AWS us-east-1 (Virginia) and many Asia-Pacific regions still heavily coal-dependent. Use the Electricity Maps API or Cloud Carbon Footprint tool to check current carbon intensity. For fixed-time workloads, running in the lowest-carbon available region can reduce emissions by 3–5× compared to the highest-carbon region.

npm package size affects carbon through two mechanisms: download emissions (each time a developer or CI pipeline installs a package, the package data is transmitted over the network, consuming energy proportional to data volume) and runtime emissions (larger JavaScript bundles delivered to users consume more energy to transmit over mobile networks and more CPU to parse and execute in browsers). For widely used packages, even small size reductions multiply across millions of installs. The npmjs.com package page now shows download counts — a package with 10 million weekly downloads saving 50KB per install saves 500GB of network transfer per week. Use Bundlephobia and pkg-size to measure package impact before publishing.

Kepler (Kubernetes-based Efficient Power Level Exporter) is a CNCF sandbox project that measures the energy consumption of individual Kubernetes pods using hardware performance counters, eBPF probes, and power model estimation. It exposes per-pod energy metrics as Prometheus metrics, enabling teams to measure the actual energy consumption of their workloads rather than relying on whole-server estimates. Kepler works by reading CPU performance counters (instructions executed, cache misses, memory bandwidth) for each pod and applying a trained power model to estimate energy consumption proportional to resource usage. This enables true per-workload carbon accounting at the Kubernetes level — essential for implementing SCI measurement in container-based deployments.