We cut CI emissions by up to 90% – by choosing where code runs

We’ve been experimenting with running CI/CD jobs multi-cloud, across AWS, Azure, and GCP — but with a twist: each job gets routed to the lowest-carbon region available at the time (among other weightings like latency, performance, and provider preferences).

There’s a surprising amount of variability between cloud regions. Some run on hydro, nuclear, or wind — others are still coal- or gas-heavy. By choosing where code runs based on carbon intensity, we’ve seen up to 90% reduction in emissions per job, without changing app logic or infrastructure. Also 25% cheaper too.

For example:

We’ve been tracking the average grid intensity of jobs run by GitHub Actions and Azure (when region is unspecified), and we’ve seen an average of ~285 gCO₂/kWh.By contrast, when we set a hard limit of 100 gCO₂/kWh max, our jobs averaged just 48 gCO₂/kWh — with some running as low as 24 gCO₂/kWh.

It’s been eye-opening to see how much of a difference regional scheduling can make — especially for something like CI/CD, where latency is often a lesser concern.

It’s made us wonder:

- Should developers be thinking about this, or should platforms abstract it away? - Where’s the right tradeoff between performance, carbon, and cost?

If anyone else here is exploring carbon-aware infra, cloud sustainability, or multi-cloud scheduling

We built this into tool called CarbonRunner that automates this process. It pulls live grid intensity data and applies weighted logic to select the best region for each job across providers — would love to hear what you're seeing or thinking about.