Most cloud sustainability tools are built for sustainability officers.

They pull three-month-old billing data, run it through a proprietary model, and produce a PDF that engineers never see.

By the time you know your us-east-1 cluster emits twice as much as us-west-2 would have, it's been running for a quarter. The architecture is locked in. The carbon is already burnt.

The only moment you can actually change what gets deployed is the pull request.

So I built a tool that lives there.

What GreenOps CLI does

It's a GitHub Action that reads a terraform show -json plan output and posts a carbon and cost diff directly on the PR, across AWS, Azure, and GCP, before anyone clicks merge.

Here's what it posted on a real PR this week:

🌱 GreenOps Infrastructure Impact

Metric                    Monthly Total
Scope 2 — Operational     21.23 kg CO₂e
Scope 3 — Embodied         4.17 kg CO₂e
Total Lifecycle           25.40 kg CO₂e
Water Consumption          22.5 L
Infrastructure Cost       $280.32/month

Potential savings: −20.75 kg CO₂e/month (97.7%)
💡 3 recommendations found

Resource               Type         Region     Action
aws_instance.web       m5.xlarge    us-east-1  → eu-north-1
aws_instance.api       m5.large     us-east-1  → eu-north-1
aws_db_instance.main   db.m5.large  us-east-1  → eu-north-1

That 97.7% saving exists because eu-north-1 (Stockholm) runs on near-zero carbon electricity at 8.8g CO₂e/kWh. us-east-1 sits at 384.5g CO₂e/kWh. The same infrastructure. Forty-four times the emissions. GreenOps surfaces that before you ship it.

The math is open

Every number comes from a static factors.json ledger you can read in ten minutes. The formula:

W_cpu    = W_idle + (W_max − W_idle) × utilisation
W_memory = memory_gb × 0.392 W/GB     ← CCF v3 standard
W_total  = W_cpu + W_memory
energy_kwh = W_total × PUE × 730h / 1000
co2e_g     = energy_kwh × grid_intensity_gco2e_per_kwh

For m5.large in us-east-1 at 50% utilisation this produces 5,308g CO₂e/month. That value is asserted in engine.test.ts. You can verify it yourself from factors.json in under five minutes.

PUE differs by provider: AWS 1.13, Azure 1.125, GCP 1.10. Memory power draw is constant, DRAM draws near-constant power regardless of CPU utilisation, which is why memory-optimised instances carry disproportionately higher emissions than their vCPU count suggests.

The full methodology is at getgreenops.com/methodology. MIT-licensed. If you disagree with an assumption, open a PR.

It also posts inline suggestions

With post-suggestions: true, GreenOps posts a committable suggestion directly on the instance_type line in the PR diff.

The developer sees the suggestion in the Files changed tab. One click on "Commit suggestion" and the instance type is updated in place. No separate PR. No separate ticket. The carbon reduction is captured at the same moment the infrastructure decision is made.

It tracks history on the dashboard

Every run posts to getgreenops.com via an optional API key. The dashboard shows:

• Total lifecycle CO₂e saved across all PRs
• Trend chart over the last 90 days
• Per-repository leaderboard
• Per-run resource breakdown — every instance, every recommendation, every skipped resource with the reason why

Two lines of YAML

- name: GreenOps Carbon Analysis
  uses: omrdev1/greenops-cli@v0.7.0
  with:
    plan-file: plan.json
    github-token: ${{ secrets.GITHUB_TOKEN }}
    post-suggestions: true
    api-key: ${{ secrets.GREENOPS_API_KEY }}   # optional — enables dashboard

Requires only pull-requests: write. No cloud credentials. No outbound network calls from the CLI. Works in air-gapped and SOC 2 environments where SaaS carbon tools cannot be deployed.

You can also enforce carbon budgets

Add .greenops.yml to your repo root:

version: 1
budgets:
  max_lifecycle_co2e_kg: 10
  max_pr_cost_increase_usd: 500
fail_on_violation: true

fail_on_violation: true exits with code 1. The merge is blocked. The PR comment shows which constraint was breached and by how much.

Why this matters for CSRD

The EU Corporate Sustainability Reporting Directive requires large companies to report Scope 2 and Scope 3 emissions from 2024 onwards, with SMEs following from 2026.

Cloud infrastructure is one of the largest and fastest-growing sources of corporate Scope 2 emissions. Most companies have no mechanism to trace which team, which PR, which infrastructure decision drove which emission.

GreenOps creates that audit trail — per PR, per repository, per engineer — at the point where the decision was made. The methodology is CCF v3 aligned. Every formula is documented. Every number is testable.

Current coverage

• ✅ AWS — 40 instance types across 14 regions
• ✅ Azure — 16 instance types across 8 regions
• ✅ GCP — 15 instance types across 7 regions
• ✅ Scope 2 operational + Scope 3 embodied + water consumption
• ✅ ARM instance upgrade recommendations (Graviton, Ampere Altra, T2A)
• ✅ Region shift recommendations based on grid carbon intensity
• ⚠️ Lambda/serverless — flagged as unsupported, not silently ignored

Try it in 5 minutes

Fork github.com/omrdev1/greenops-e2e-demo — it has the workflow, a Terraform config with intentionally high-carbon instances, and runs without an AWS account. Open a PR and GreenOps runs automatically.

Or add it to any existing Terraform repo:

- name: GreenOps Carbon Analysis
  uses: omrdev1/greenops-cli@v0.7.0
  with:
    plan-file: plan.json
    github-token: ${{ secrets.GITHUB_TOKEN }}

No API key needed for the PR comment. The dashboard is optional.

→ github.com/omrdev1/greenops-cli
→ getgreenops.com
→ getgreenops.com/methodology

Built by Omar — Co-founder, Grafikui. Open source, MIT-licensed.