SuperCI vs the Terraform module for runners on AWS
Both are open source and start EC2 machines for GitHub Actions jobs. The module is infrastructure you deploy and keep with Terraform; SuperCI is set up from a dashboard and also runs elsewhere.
terraform-aws-github-runner is a Terraform module that, in its own words, “creates the required infrastructure needed to host GitHub Actions self-hosted, auto-scaling runners on AWS spot instances”. It was started at Philips Labs and is now kept by its community. Like SuperCI it is open source under the MIT licence, and like SuperCI it runs nothing but functions between jobs.
Side by side
| What | SuperCI | terraform-aws-github-runner |
|---|---|---|
| Set up with | A dashboard on your computer, or commands | Terraform, and a GitHub App you make by hand |
| It creates in AWS | A Lambda function, a table, a schedule, and a machine per job | An API Gateway, several Lambda functions, an SQS queue, an S3 bucket, and machines |
| One job per machine | Always | An option, off by default |
| Spot machines | By default; a job that loses one runs again on demand | By default |
| Runs jobs in | AWS, Cloudflare, Modal | AWS |
| Works with | GitHub Actions and GitLab CI | GitHub Actions |
| Systems | Linux and Windows | Linux and Windows; macOS as an experiment |
| Licence | MIT | MIT |
Setting up
The module’s own guide describes the order of work:
The setup consists of running Terraform to create all AWS resources and manually configuring the GitHub App. The Terraform module requires configuration from the GitHub App and the GitHub App requires output from Terraform.
So you make the App, run Terraform, and go back to finish the App. The Lambda functions’ code has to be downloaded or built first, and your account needs the role AWS uses for spot machines.
With SuperCI, one command opens a dashboard:
npx @superci/cli dashboardYou sign in with AWS there. It deploys the control plane, makes the GitHub App for you, and you choose its repositories. The same steps exist as commands for a script or a coding agent.
One job per machine
By default the module reuses a runner for job after job until it has been idle for a while. Runners that take one job each are an option, and its security page says “we strongly suggest” them. Its guide is open about what that mode cannot promise: a runner started for one job may be given another, and if an event is lost, “potentially no runner gets created and the job in GitHub times out in 6 hours”.
SuperCI only works one way. Each machine is registered with GitHub as a runner for exactly the job it was started for, runs it, and is ended. A machine whose job never came is cleaned up, and a job whose machine could not start goes to the next provider in your order.
Where the module is the better choice
- Your infrastructure is all Terraform. Then runners belong in the same code, reviews and state as everything else. SuperCI makes its few resources itself.
- You want to shape every part. The module exposes its machine images, networks and pools of idle runners as variables.
- You need macOS. The module has experimental support for EC2 Mac machines. SuperCI has none.
Pick SuperCI if you would rather not write or keep Terraform for CI, if you want Cloudflare or Modal as well as AWS, or if you run GitLab CI too.
Sources
Read on 9 October 2026.
- terraform-aws-github-runner on GitHub: what it is, its licence and history, the systems it supports, its defaults.
- The module’s documentation: what it creates in AWS.
- Getting started: the order of set-up, the Lambda functions’ code, the spot role.
- Configuration: reused and one-job runners, what one-job runners cannot promise, macOS.
- Security: its advice to use one-job runners.