Heata Runners

Faster CI/CD. Lower costs. Reusing the heat from the servers for good.

Heata Runners are GitHub Actions runners hosted on Heata's distributed, low-carbon compute infrastructure. Your CI/CD workflows run on dedicated, isolated infrastructure while the heat from that compute provides free hot water to UK households.

Same GitHub Actions. Same workflow files. One line change.

Why Heata Runners?

Save money

GitHub-hosted runners cost $0.008/minute on the standard tier. From March 2026, even self-hosted runner minutes on private repos incur a $0.002/minute charge from GitHub.

Heata Runners are priced competitively below GitHub's hosted offering, with the performance of dedicated bare-metal hardware. Our machines run 52 to 126 cores each, and your jobs get dedicated CPU and RAM - not shared, not throttled, not queued behind other customers.

Larger caches, faster networks, and warm local package mirrors mean your builds finish sooner. Less time running = less cost.

Low carbon compute

Traditional data centres generate enormous amounts of waste heat that is simply vented into the atmosphere. Heata is different.

Our servers are distributed across UK households, where the heat generated by your CI/CD workloads is captured and used to provide free hot water. Each Heata unit prevents approximately 1 tonne of CO2 equivalent per year compared to traditional data centre compute plus household water heating combined.

Your CI pipeline is going to run anyway. It might as well provide free showers!

Heata places compute hardware in the homes of people who need it most, including households in fuel poverty. The waste heat from your CI/CD builds provides them with free hot water, every day. Backed by British Gas and covered in MIT Technology Review, this isn't a theoretical offset - it's a direct, physical benefit to real households.

We can provide you with a quarterly impact report showing the real-world effect of your compute usage.

How it works

Your GitHub repo                     Heata infrastructure
      │                                      │
      │  1. Workflow triggers                │
      │     (push, PR, schedule)             │
      │                                      │
      │  2. GitHub sends event ────────────> │
      │                                      │
      │  3. Fresh runner boots               │
      │     (~20 seconds)                    │
      │                                      │
      │  4. Job runs on dedicated            │
      │     isolated runner                  │
      │                                      │
      │  5. Results reported                 │
      │  <──────────────────────────────     │
      │                                      │
      │  6. Runner destroyed                 │
      │     (clean slate for next job)       │

No infrastructure to manage. No tokens to rotate. No servers to maintain.

Switching is trivial

To Heata (10 minutes)

Install our GitHub App on your org (one click)
Change runs-on: in your workflow files:

# Before
runs-on: ubuntu-latest

# After
runs-on: yourprefix-heata-standard

Push. Done.

Back to GitHub (2 minutes)

# Just change it back
runs-on: ubuntu-latest

No lock-in. No dependencies. No cleanup. Your workflow files are standard GitHub Actions and work identically on any runner. We don't require custom actions, proprietary syntax, or wrapper scripts.

Security

We take security seriously. Here's how your workloads are protected:

Your workloads are protected by two layers of isolation:

Client isolation — Each client's runners operate within their own dedicated virtual machine (KVM/QEMU), fully separated from all other clients at the hardware level. Your VMs cannot see or communicate with any other client's VMs.

Job isolation — Within your VMs, each job gets a fresh, ephemeral runner created from a clean image and destroyed immediately after. No state carries over between jobs — no previous job's files, processes, or credentials can leak.

Concern	How we handle it
Secrets	Your repository secrets are injected by GitHub, not by Heata. We never see, store, or have access to your secrets, tokens, or credentials.
Code access	The Heata GitHub App only has permission to manage runner registrations. It cannot read your code, access your issues, or view your pull requests.
Private repos only	We only support private repositories. This eliminates the class of attacks where untrusted fork PRs execute code on self-hosted runners.
Short-lived credentials	Runner authentication uses GitHub's JIT (Just-In-Time) tokens that are single-use and expire within one hour. No long-lived credentials exist on our infrastructure.

We're happy to discuss our security model in detail with your security team and can provide additional documentation on request.

What you get

Dedicated resources, not shared

Unlike GitHub-hosted runners where you share infrastructure with the world, your Heata runners get dedicated CPU and RAM allocations:

Tier	vCPU	RAM	Storage	Price/Min	GitHub Equiv.	Savings	Ideal Use Case
heata Slim	2	5 GB	30 GB	£0.0007	`ubuntu-slim`	~53%	Linting, small unit tests, and lightweight automation
heata Standard	4	8 GB	50 GB	£0.0030	`ubuntu-latest`	~32%	Docker builds and heavy integration tests
heata Large	8	32 GB	100 GB	£0.0059	`linux-4-core`	~34%	Large-scale data processing and monolithic builds

Every tier offers double the vCPU compared to the equivalent GitHub-hosted runner. heata Large also doubles the RAM versus GitHub's 4-core runner.

Local caching

Each Heata host machine runs a high-speed local cache layer that sits on the same physical network as your runners:

Docker image cache - Common base images are pulled once and cached locally. No more waiting for docker pull on every build.
Package manager cache - npm, pip, and other package managers are transparently proxied through a local cache. npm install on a warm cache completes in seconds, not minutes.
Build artifact cache - An optional drop-in replacement for actions/cache that stores artifacts on local storage instead of GitHub's servers. No 10 GB size limit.

These caches are transparent - they work automatically without any changes to your workflows.

Multi-repo, one setup

Install the GitHub App once on your organisation. Every repository you authorise can use Heata runners immediately. No per-repo configuration. No runner tokens to manage per repo.

What we need from you

Install our GitHub App on your GitHub org (takes 30 seconds)
Tell us your desired concurrency - how many jobs you'd like to run in parallel
Update your workflow files - change runs-on: labels

That's the entire onboarding. No infrastructure provisioning, no VPN setup, no firewall rules, no server access.

Frequently asked questions

Can I try it on one repo first? Absolutely. When installing the GitHub App, choose "Only select repositories" and pick one to start with. You can add more repos at any time from your GitHub org settings.

What if I decide to stop using Heata? Change runs-on: back to ubuntu-latest and your workflows immediately run on GitHub's infrastructure. There is zero dependency on Heata beyond the runner label.

Can I mix Heata and GitHub-hosted runners? Yes. Different jobs in the same workflow can use different runners. Run your fast linting on GitHub-hosted runners and your heavy builds on Heata - or vice versa.

Do you support Windows or macOS runners? Currently Linux (Ubuntu 24.04) only. Contact us if you have Windows or macOS requirements.

How does billing work? We offer simple per-minute pricing or monthly packages based on your usage profile.

Get started

Interested? Get in touch:

Email: runners@heata.co
Web: heata.co
Demo: We can set up a proof-of-concept on a test repo in under an hour

Every build heats a home.