FAQs

🧭 Core Concepts

Want to get familiar with the terminology? Check out our Glossary— it's packed with clear, concise definitions of cloud compute terms, from workflows to workloads and everything in between.

• What's the difference between a job and a workload?

  While often used interchangeably, jobs and workloads represent different levels of granularity in computing tasks. A job is a specific, discrete unit of work with clear boundaries—like "run unit tests" or "deploy to staging." A workload is broader and encompasses the overall computational demand, which may include multiple jobs and focuses on resource consumption patterns.

  In GitHub Actions, a job is a defined unit in your workflow file (like build, test, or deploy), while the workload represents the total computational demand those jobs create on GitHub's infrastructure. For example, your CI/CD workload might consist of multiple jobs: building the application, running tests in parallel, and deploying to different environments. Each job is a discrete task, but together they form the workload that consumes CPU, memory, and network resources across GitHub's runners.

  Analogy: Think of jobs as individual errands (pick up groceries, mail a package, get gas) while the workload is your overall "running errands" activity that requires time, transportation, and energy resources.

• 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

• What does CarbonRunner actually do?

  CarbonRunner is an intelligent carbon-aware workload orchestrator that routes jobs—like CI/CD builds, AI model training, Data pipelines, Batch processing and render jobs — to the lowest-carbon region in real time.

• 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.

👩‍💻 Techie Questions

• What if a company says “we’re on-prem” but uses OpenStack?

  That’s likely a private cloud—we can work with it if it spans multiple regions.

• Can CarbonRunner be used without GitHub?

  Yes, we accept other sources like BitBucket and Gitlab. Also workloads through API-submitted jobs, Docker containers, and job specs.

🔐 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. Sign-up for CarbonRunner and login.
  2. 2. Follow the setup steps to 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.