Written by Albert Friedman
on 

Carbon‑Aware CI/CD: Turning Real‑Time Grid Emissions Into Greener Deploys

Sustainability in DevOps isn’t just about reporting anymore. Over the past few cycles, the building blocks for practical, day‑to‑day emissions reduction have matured: we have an ISO standard to measure software emissions, widely used open tooling to fetch carbon‑intensity data, and a new standard that pushes cloud providers toward real‑time transparency. If you run CI/CD and Kubernetes today, you can start cutting carbon without slowing your teams down.

This article shows a simple, production‑friendly way to make your pipelines carbon‑aware: measure a baseline, add an emissions “gate” to CI, pick greener regions for batch jobs, and close the loop with runtime telemetry. Along the way, I’ll point to the standards and tools that make this work credible and repeatable.

What’s new (and why it matters)

A practical workflow you can ship this sprint

Here’s a minimal, low‑risk path to carbon‑aware DevOps. It doesn’t require rewriting apps or changing orchestrators—just a few smart checks in your pipeline and some telemetry.

1) Establish a baseline you can defend

Deliverable for your backlog: a dashboard with SCI by pipeline and Kepler power by workload.

2) Add a carbon‑aware “gate” to CI

Goal: If a greener 15‑ to 60‑minute window is imminent, delay a non‑urgent job (e.g., nightly builds, integration tests, data pipelines) until then. If not, run now. This is deadline‑aware and developer‑friendly.

You can use the Carbon Aware SDK as a CLI (or Web API) inside your runner. The CLI exposes emissions forecasts and returns the best window for a given workload duration. (carbon-aware-sdk.greensoftware.foundation)

Example: GitHub Actions job that waits (up to 45 minutes) for a cleaner window in a chosen region using Electricity Maps as the data source.

name: carbon-aware-build
on:
  workflow_dispatch:
  schedule:
    - cron: "0 * * * *"  # hourly

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      DataSources__EmissionsDataSource: ElectricityMaps
      DataSources__ForecastDataSource: ElectricityMaps
      DataSources__Configurations__ElectricityMaps__Type: ElectricityMaps
      DataSources__Configurations__ElectricityMaps__APITokenHeader: auth-token
      DataSources__Configurations__ElectricityMaps__APIToken: $
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "8.0.x"

      - name: Build Carbon Aware CLI
        run: |
          git clone https://github.com/Green-Software-Foundation/carbon-aware-sdk.git
          dotnet publish ./carbon-aware-sdk/src/CarbonAware.CLI/src/CarbonAware.CLI.csproj -c Release -o ./caw

      - name: Wait for greener window (max 45 min)
        run: |
          sudo apt-get update && sudo apt-get install -y jq
          FORECAST=$(./caw/caw emissions-forecasts -l eastus -w 30)
          BEST_TS=$(echo "$FORECAST" | jq -r '.[0].optimalDataPoint.timestamp')
          NOW=$(date -u +%s)
          BEST_EPOCH=$(date -d "$BEST_TS" +%s)
          DELAY=$((BEST_EPOCH - NOW))
          MAX_DELAY=$((45*60))
          if [ $DELAY -gt 0 ] && [ $DELAY -le $MAX_DELAY ]; then
            echo "Sleeping $DELAY seconds until greener window at $BEST_TS (eastus)…"
            sleep $DELAY
          else
            echo "No greener window within 45 minutes—continuing now."
          fi

      - name: Run tests
        run: |
          ./scripts/run-tests.sh

Notes:

3) Let your pipeline pick the greenest region for batch jobs

If your workload can run in multiple cloud regions, query forecasts for each and choose the one with the lowest expected intensity for your job’s window.

Example snippet (bash + jq):

FORECAST=$(./caw/caw emissions-forecasts -l eastus -l westus2 -w 20)
BEST_REGION=$(echo "$FORECAST" | jq -r 'map({region:.location, val:.optimalDataPoint.value}) | sort_by(.val) | .[0].region')
echo "Deploying batch job to $BEST_REGION"
# export to pipeline env if needed

This is the “location shifting” half of carbon‑aware computing; the previous step handled “time shifting.” The SDK abstracts over data providers (e.g., Electricity Maps, WattTime), so you can swap sources without changing your pipeline. (greensoftware.foundation)

4) Close the loop at runtime

What kind of impact should you expect?

Published research on carbon‑aware scheduling suggests impressive headroom when workloads are flexible:

The takeaway: start with deadline‑tolerant jobs, keep a modest max delay (e.g., ≤45 minutes), and iterate from there.

Guardrails that keep developers happy

What to watch next

Wrap‑up

Sustainable DevOps doesn’t need a moonshot. With an ISO‑standard measurement (SCI), a mature carbon‑intensity SDK you can call from any pipeline, and a push toward real‑time cloud emissions data, teams can make pragmatic, incremental changes that add up. Start by gating non‑urgent jobs to greener windows, teach your pipeline to prefer cleaner regions, and measure the effect with SCI and runtime telemetry. You’ll likely see meaningful carbon reductions without sacrificing delivery speed—and you’ll have a defensible story when you share results with your organization. (iso.org)