We cut CI emissions by up to 90% – by choosing where code runs
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.
Considering the millions of instructions that nowadays are executed just to cope with all layers of abstraction to read a sigle byte from a drive, we really need to start thinking about energy consumption and energy-efficient programming!
When it's too cool, I spin up a kernel build, after a while the room is warmed by the heat of the CPU.