FAQs

🧭 Core Concepts

• What is a compute job?

  A compute job is a specific task that requires computational resources to complete. In the context of GitHub Actions, a compute job is a set of steps that run on a server when triggered by events like code pushes, pull requests, or scheduled times. These jobs might include building your code, running tests, deploying applications, or generating documentation. CPU, memory, disk, etc.

  It's like hitting "Run" on a process that consumes

• What is a workload?

  A workload is more like a collection or type of compute jobs.

  Your entire CI/CD (Continuous Integration/Continuous Delivery) pipeline represents a workload - all the testing, building, packaging, and deployment processes that happen automatically when you work with your code repository. Workloads consume computing resources including processing power, memory, and electricity.

  Compute job = one task (e.g., run tests)

  Workload = many tasks or a group/type of jobs (e.g., CI pipeline)

• What is load shifting?

  Load shifting is a sustainability strategy that moves electricity consumption from times when the grid is "dirty" (high carbon intensity from fossil fuels) to times when it's "clean" (high renewable energy percentage). With CarbonRunner, this means scheduling your GitHub Actions workflows to run when and where the electrical grid has the lowest carbon emissions.

• What is a location-based approach?

  The location-based approach looks at where your compute happens and what the electricity mix is in that region at the time of use. For example, if your job runs in a region where electricity is mostly coal-based at that moment, your emissions are higher — regardless of your cloud provider's overall energy procurement.

• What is hourly matching?

  Hourly matching means matching your energy usage to clean energy production on an hour-by-hour basis. Instead of saying “we bought clean energy this year,” hourly matching proves that you used clean energy at the exact time your systems were running, which is far more precise and impactful.

• What is 24/7 CFE (Carbon-Free Energy)?

  24/7 CFE means powering your compute with carbon-free energy every hour of every day, not just buying offsets or annual credits. It’s a new gold standard for sustainability, pioneered by Google and others, that focuses on continuous clean energy usage, not just averages.

• What is a market-based approach?

  A market-based approach considers what energy contracts or renewable energy credits (RECs) your company has purchased — not necessarily what energy was used at the time or location. While it’s widely used, it can be misleading, since you could be using fossil power but still claim to be “green” based on credit purchases elsewhere.

🧠 General Questions

• How does it work?

  CarbonRunner monitors real-time carbon intensity data from around the world. When your workflow runs, we: Look up which regions currently have the cleanest electricity Check which servers are available in those regions (across AWS, Azure, GCP) Route your GitHub Actions job to the cleanest location — automatically This all happens behind the scenes, within seconds.

• What does CarbonRunner actually do?

  CarbonRunner is a specialized GitHub Actions solution that significantly reduces the environmental impact of your compute jobs or workloads (like code testing, building, and deployment processes).

• Can I choose where my jobs run?

  Absolutely. We support region preferencing, so if you need to run all jobs within a specific location like the UK, we can do that.

  Just note that while the UK has some renewable energy, it’s not always the cleanest option. So instead of our typical 90% CO₂ reduction (or 14x cleaner), you might see more like a 5x improvement — still meaningful, just not as dramatic.

• How does CarbonRunner work?

  We monitor real-time carbon intensity data across the globe to identify regions where electricity is currently the most renewable. We maintain access to a diverse network of servers across cloud providers like AWS, Azure, and GCP in these low-carbon regions.

  When your GitHub Actions workflow triggers (e.g., on code push or pull request), we cross-reference this carbon data with our server inventory to find the best location. Your CI jobs — tests, builds, deployments — are then automatically routed to servers in the cleanest energy regions.

  This results in up to a 90% reduction in CO₂ emissions compared to standard runners. We also consider factors like local water scarcity, so we're not solving one environmental issue while worsening another.

• How do you calculate the emissions of each CI job?

  We estimate emissions of each CI job in a few steps...

  • Step 1: Estimating Energy Usage - We look at a few key values: CPU Thermal Design Power (TDP), CPU Utilization and other Overhead factors – accounts for the rest of the system: RAM, disk, networking, cooling, etc. With these, we estimate Total Energy Usage per Minute, and multiply by the duration of the job.
  • Step 2: Understanding the Grid - Next, we look at where the job ran, and determine the carbon intensity of that cloud region at the time of execution. We then look at live energy generation data of all regions within our multi-cloud. This shows the real-time carbon intensity of electricity in grams of CO₂ per kilowatt-hour (gCO₂/kWh) for that location.
  • Step 3: Calculating CO₂ Emissions - With both energy usage and grid intensity, we estimate emissions:
    
    Total Emissions (gCO₂) = Energy Used (kWh) × Grid Intensity (gCO₂/kWh).
    
    This gives us a job-level view of how much carbon is emitted by each CI run. By measuring emissions this way, we can directly compare jobs running in different cloud regions — and make smarter, lower-impact decisions based on real data.

• Why does shifting CI jobs even matter?

  The wild world of Reddit never fails to surprise us — it’s a mix of mostly keyboard warrior, random questions, thoughtful comments, and plenty of unexpected insights. For us, it’s a goldmine of perspectives and potential content.

  We actually enjoy the challenge of stepping outside our comfort zone and thinking through unfamiliar or uncomfortable points of view.

  So when we started seeing a wave of “What’s the point?” questions — and comments like the one below — we figured it was time to respond. Not reactively, but after a bit of debate and reflection of our own.

  "a Taylor Swift flying private or an Oil spill or COWS for that matter are more harmful to the environment than a CI job."

  I get where you're coming from (kind of) — sure, Taylor Swift's jet, oil spills, and methane from cows all have a huge environmental impact.

  But using that as a reason not to act anywhere else misses the point. We're not pretending CI/CD is the biggest climate issue (see project drawdown) — but it’s part of a system we do know and can influence. We’re not in aviation, we don't run oil rigs, and we don’t farm cattle. We work in tech, and we've chosen to focus on what we can change.

  We've found that action is better than anxiety, and we care deeply about the environment we live and work in. Rather than sitting back and critiquing, we built something — because it matters to us. And along the way, we discovered it saves money too.

  Small steps can still lead to big shifts — especially when done with intention.

🔐 Security & Control

• What is the patching schedule like for the runners?

  An automated nightly build of all base images is created including all of the latest security updates for the Operating System.

  Github Runners are updated within 24h of a release to give us time to test the new version.

• What is being logged/captured on the runners?

  We send up the log of `runinit`, a program which is started on boot to initiate the connection between CarbonRuner and Github/Gitlab etc... The output of this program is sent up via Syslog (TLS), otherwise we do not log anything.

  `runinit` will log your Github organization/username, repo name, CPU frequency settings and network byte counters (Rx+Tx).

• Are there any prepackaged tools on the runners and how often are they updated?

  Yes. If you've chosen the standard CarbonRunner `ubuntu-latest` images then we stick to the same packages that are installed by Github.

• What controls do we have around which regions things run in? e.g. can we only allowlist European ones?

  Yes. Github Runners are usually installed at the Organization level which means that any runners we spin up for you can take the workflow in any available CarbonRunner region.

  In your Dashboard you can restrict which regions and providers are used. This is best for the general case as the developer does not have to adjust the runs-on tag beyond the initial change.

⚙️ Using CarbonRunner

• How do I start using CarbonRunner?

  1. 1. Add the Github CarbonRunner App
  2. 2. Configure it to a particulate repositories or across all repositories.
  3. 3. Change the runs-on line in your workflows file.
  4. 4. Login to your CarbonRunner dashboard to see workflows being processed. (You'll also get an email when we receive the first job.)

• What happens when I change the runs-on line?

  You're telling GitHub to use our runner instead of their default one. We take care of: Matching the environment (Linux, Ubuntu, Node, etc.) Spinning up a fast, clean-energy runner in the best available region Running your job as usual Nothing else in your workflow needs to change.