SuperCI

Your GitHub Actions and GitLab CI jobs, on fresh machines in your own AWS, Cloudflare or Modal account.

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.

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 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.
• Runner agents (crates/runners-cloudflare, and a Modal app in crates/cli/src/modal_agent.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.

License

MIT. See LICENSE.