GitHub Actions Runner

Use Chaser as a self-hosted GitHub Actions runner. Your CI/CD jobs run inside Chaser microVMs instead of GitHub’s hosted runners or third-party runner services.

Setup

1. Open the Chaser dashboard and connect your GitHub account. The dashboard handles installation, repo selection, and authentication on your behalf — no PATs to mint, no runner registration tokens to copy.
2. In your workflow file, set runs-on: chaser:

1
# .github/workflows/ci.yml
2
name: CI
3
on: [push, pull_request]
4
5
jobs:
6
  test:
7
    runs-on: chaser
8
    steps:
9
      - uses: actions/checkout@v4
10
      - run: npm ci
11
      - run: npm test

That’s it. When GitHub fires a workflow_job event for that job, Chaser picks it up, boots a microVM, runs the job, and reports the result back to GitHub.

Why Chaser as a runner

• Faster than alternatives — including Blacksmith. Chaser’s microVMs boot in seconds and are backed by the same density-tuned infrastructure that powers our browser and sandbox sessions. CI jobs that wait on cold starts and slow runner pools land sooner.
• Real isolation — every job runs in a fresh microVM with its own kernel. Not a shared container, not a reused worker.
• Predictable cost — usage is metered against your Chaser account, alongside any sandbox or browser sessions you already use.

Labels

Any runner label of the form chaser or chaser-* routes through Chaser. Use the suffix form (e.g. chaser-large, chaser-gpu) when you have multiple runner classes configured for your account.

1
jobs:
2
  build:
3
    runs-on: chaser-large

Under the hood

The github.runner job kind handles workflow_job events end-to-end. See Jobs for the queued-execution model that backs runner jobs.

Related

• CI/CD Integration — broader CI patterns including direct exec and queued pipelines
• Jobs — job kinds and scheduling
• Sandbox Sessions — the underlying sandbox surface