SuperCI

OpenRouter for CI, and the cheapest way to run GitHub Actions: each job goes to the first cloud that can run it (AWS spot, Cloudflare, Modal, AWS on-demand when spot is full), in your own accounts at their prices with nothing added. On AWS spot, a 2 vCPU job costs $0.0008 a minute, against $0.006 on GitHub's runners. One command sets it up; there are no servers or Kubernetes to run. Free and open source (MIT), and an alternative to RunsOn, Blacksmith and Actions Runner Controller.

It also runs GitLab CI jobs.

npx @superci/cli dashboard

That opens your dashboard, on your own computer. Sign in with your cloud, put a control plane there with one click, connect a repository, and change one line in a workflow:

jobs:
  test:
    runs-on: superci

Each job gets a machine of its own, of the size its label asks for (superci/cpu=16, superci/arch=arm64, superci/gpu=any, superci/os=windows), and the machine is gone when the job ends. You pay your cloud's prices; there is no service of ours in between.

On Modal, a job can start from an image of your own with its tools in it already: make it FROM ghcr.io/actions/actions-runner, name it once (superci runner_images create rust-ci --reference=ghcr.io/acme/ci:2026-10), and say runs-on: superci/image=rust-ci. Give each build a tag of its own or use its digest: Modal keeps an image by its address. Move the name to a new build in one step with superci runner_images update rust-ci --reference=ghcr.io/acme/ci:2026-11. For a private registry, add --modal-secret=NAME, a Secret with REGISTRY_USERNAME and REGISTRY_PASSWORD in each Modal workspace that runs jobs: a further workspace (modal:WORKSPACE) reads its own.

Modal Functions are a row of their own in the order, as AWS's spot and on-demand are: preemptible, at a third of a sandbox's price, and taken out until you put them in: superci runners order modal-functions modal. Modal may preempt a Function; SuperCI then runs its job again by itself further down the order once its run has finished, and superci status counts the preemptions of the month.

One CI can run jobs in several AWS accounts, Cloudflare accounts or Modal workspaces, each its own runner with its own limits and spend: superci login modal --add, then superci runners create modal --account=WORKSPACE. Workflows do not change: provider=modal means every Modal runner, in the order's order.

Without Node, the same program installs as superci:

brew install supercorp-ai/tap/superci           # Homebrew
curl -fsSL https://superci.dev/install.sh | sh  # macOS and Linux, into ~/.local/bin
cargo install superci                           # built from source by Rust

Then superci dashboard.

Documentation: superci.dev/docs.

How it compares with GitHub's own runners, RunsOn, Actions Runner Controller and the hosted services: superci.dev/compare, including Blacksmith alternatives. What a month of your jobs would cost: the calculator.

To let a coding agent move a repository's jobs (from GitHub's runners, Blacksmith, Depot, Namespace, WarpBuild, Ubicloud, BuildJet or RunsOn), add the skill in skills/superci:

npx skills add supercorp-ai/superci

How it is put together

• The dashboard (crates/cli) runs on your computer. It deploys and updates everything else with SuperCI's own sign-ins to your clouds, kept in ~/.superci (it reads no other tool's credentials), by workspace when you look after several CIs from one computer; everything it does is also a command on the same sign-ins, for scripts and coding agents (superci status --json, superci planes update, superci runners update aws --max-jobs=20; superci alone lists them), and superci logout removes them.
• The control plane (crates/core, with a thin runtime for each place it can live: crates/plane-cloudflare, crates/plane-aws, crates/plane-modal) runs in your cloud account. GitHub and GitLab tell it when a job is waiting, and it starts a machine for it at the first of your providers that can run it.
• Launchers (crates/runners-cloudflare, and a Modal app in crates/cli/src/modal_launcher.py) start containers for a control plane that lives in another cloud.
• The cache program (crates/cache) runs on each AWS machine and serves GitHub's cache to the job's actions, keeping it in a bucket of the control plane's in your account; it holds no keys.
• The image reader (crates/image-reader) lets a Cloudflare container run jobs inside GitHub's full runner image without holding it on its disk.

How it is built and where its trust lines are: SECURITY.md. What changed in each version: CHANGELOG.md.

Build from source

./build.sh        # the control planes and agents the program carries inside it, then the program
cargo test --workspace
target/release/superci

build.sh needs Rust, worker-build, zig with cargo-zigbuild, and zip.

The npm packages are packed with ./scripts/npm-pack.sh (the program for macOS, Linux and Windows, and a launcher). A release is the workflow Publish to npm (.github/workflows/publish.yml), run by hand with the version: it builds, tests, tries the packages on macOS and Windows, publishes through npm's trusted publishing, and tags the release; then it publishes the crates (scripts/crates-publish.sh), writes the Homebrew formula into the tap (scripts/brew-formula.sh), and tries install.sh, all three from npm's files or the same source. Every push and pull request is built and tested by .github/workflows/test.yml.

Contributors

• Domas Bitvinskas
• Taras Kornichuk: Modal deploys in a new workspace and Modal sign-ins (#2, #7)

License

MIT. See LICENSE.