beam-logo
← All use cases

Run GitHub Actions 2x faster and 5x cheaper

Managed runners for GitHub Actions. Go 2x faster while saving 5x with Beam.

Read the docs ⟶
terminal
# Create a Linux VM for the runner and connect to it
beam vm new gh-runner
beam vm ssh gh-runner

# On the VM: download the runner from your repository's
# Settings > Actions > Runners page, then register it
./config.sh --url https://github.com/OWNER/REPO --token <TOKEN>

# Run it as a service so it starts on every boot
sudo ./svc.sh install
sudo ./svc.sh start
Why Beam

Lower your GitHub Actions bill by 5x

Faster builds, lower cost, better ergonomics. Pick all three.

Warm caches between jobs

The VM's root disk is durable, so installed toolchains, package caches, and Docker layers survive from one job to the next.

Explore docs

Docker and Compose

Build images and run containers or Compose services inside the VM, the way your workflow already does.

Explore docs

Sized for your builds

Choose CPU, memory, and disk when you create the VM, or build its image from a Dockerfile with your toolchain preinstalled.

Explore docs

Clean runners from snapshots

Save a prepared VM as a snapshot, then start a fresh VM from it for each job when you want ephemeral runners.

Explore docs

Scoped secrets and egress

Bind workspace secrets to specific hosts and restrict outbound traffic, so a job can only reach what it needs.

Explore docs

SSH in to debug

When a job fails, SSH into the runner or open its browser terminal and inspect the machine exactly as the job left it.

Explore docs
How it works

How to set up a GitHub Actions runner on a Beam VM

01

Create the VM

Create a Linux VM with beam vm new, choosing CPU, memory, and disk for your builds, then connect over SSH.

02

Register the runner

Follow the commands on your repository's Settings > Actions > Runners page to download and configure the runner, then install it as a service with svc.sh.

03

Target it from your workflows

Set runs-on to self-hosted, or to the labels you gave the runner, and GitHub routes matching jobs to your VM.

ci.yml
# .github/workflows/ci.yml
name: CI
on: [push]

jobs:
  test:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: docker compose up -d
      - run: make test
FAQ

Frequently asked questions

Will a paused VM pick up GitHub Actions jobs?

No. A paused or stopped VM isn't running the runner, and commands inside a VM don't count as activity for an idle timeout. Keep runner VMs running without an idle timeout, or start a fresh VM for each job.

Can I use self-hosted runners with public repositories?

GitHub recommends using self-hosted runners only with private repositories, because a pull request from a fork could run code on the runner machine.

Can each job get a clean runner?

Yes. GitHub recommends ephemeral runners for autoscaling: GitHub assigns an ephemeral runner one job and de-registers it afterward. Start each one from a prepared snapshot, then remove the VM when the job is done.

Can runners use GPUs, or run Windows and macOS jobs?

No. Beam VMs are CPU-only machines running Debian or Ubuntu. Use GitHub-hosted runners for Windows and macOS jobs.

How is a runner VM billed?

Per second while it runs, for the CPU and memory you choose. A stopped VM releases its compute, so it stops accruing compute charges.

Keep going

Related use cases

Agents

Run coding agents on persistent cloud VMs

Persistent VMs where Claude Code and Codex can build, test, and run.

Sandboxes

Give your AI agents a safe place to run code

Isolated sandboxes for agent-generated code, booting in seconds.

Task Queues

Fan out batch jobs across thousands of containers

Fan out batch inference and ETL across thousands of containers.

Pay as you gobilled by the millisecond

Give Your Agent Superpowers

Start shipping today and bring your vision to life

Start BuildingRead the docs