Skip to main content
You need:
  • a GitHub organization (any plan);
  • a private repository in it with a GitHub Actions workflow;
  • owner rights in the organization, so you can install a GitHub App.

​
1. Install the Coreload CI App

  1. Open https://github.com/apps/coreload-ci/installations/new (GitHub asks you to sign in first if you aren’t).
  2. Choose your organization, then Only select repositories, and pick your repository.
  3. Click Install.
GitHub brings you back to Coreload’s setup page. Accept the terms there (one click), and your organization is ready. (coming soon) The App asks only for:
  • Organization self-hosted runners: write
  • Actions (the repositories you choose): read
  • Metadata (the repositories you choose): read
The self-hosted runners permission covers your whole organization: Coreload uses it only for its own runner group and the single-use runners it registers there, and never touches your other runners or groups. The App has no access to your repository contents, issues or secret values; see the security model. Your jobs run on our machines, so a job’s own checkout and files live in its VM until the job ends.
One step is still manual. After you install, we turn your organization on by hand and send you its labels. You don’t send us anything: we see the installation. Jobs wait until then.

​
2. Change one line

Use the label we sent you when we turned your organization on; the diff shows coreload. Every organization gets the coreload label. (coming soon) For a bigger machine, use a size from this table that your organization has (4 and 8 vCPU for every organization (coming soon)): Beta pricing: published before we bill anything Use exactly one Coreload label, on its own. A job that also asks for self-hosted or linux won’t start on Coreload. Jobs you don’t change keep running where they ran before.

​
3. Push and watch it run

  1. Commit and push.
  2. Open the run under your repository’s Actions tab.
  3. The job’s Set up job step names the runner coreload-…. The job runs in a fresh VM, which is destroyed when the job ends.
If the job doesn’t start, see Troubleshooting.

​
What runs today

Each job runs in a fresh VM built from a Debian 12 image with Node.js, npm, Python 3 and git. It is not yet the Ubuntu image GitHub’s ubuntu-24.04 runners use, so today:
  • No Docker. docker is not available in jobs yet: a step that runs docker or builds an image fails, and so a job’s container: and services: can’t start either.
  • Setup actions that download Ubuntu-only builds may fail. actions/setup-python fails today when it downloads a CPython version (3.12, 3.13 and 3.14 were tried): those builds are made for Ubuntu only. Other setup-* actions that fetch Ubuntu builds may fail the same way.
  • Some standard tools aren’t preinstalled, for example Go and Rust: a job that expects go or cargo on the path fails. Install them in the job: actions/setup-go works for Go.
  • Verified to work in our benchmark runs: actions/checkout, actions/setup-node, pnpm/action-setup, actions/setup-go and actions/cache (restore and save), and whole Node.js (pnpm, turbo) and Rust (cargo build and test) jobs. Other actions may work too; they aren’t verified yet.
The same image GitHub’s ubuntu-24.04 runners use, with Docker and the standard toolchains. (coming soon)

​
Set up with your coding agent

Paste this into Claude Code, Codex or another agent, in your repository:

​
Good to know

  • One job per VM. Each job gets a new VM, which never serves a second job and is destroyed when the job ends.
  • Billing. Prepaid credit, pay as you go from your balance, by the second for the time a job runs. (coming soon) Prices: see Pricing.
  • Never allowlist our addresses. A job’s traffic leaves from shared addresses, which can change.
  • Leaving. Uninstall the App, and we release your organization by hand. Uninstalling releases your organization by itself. (coming soon)