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.
