// the find
github-aws-runners/terraform-aws-github-runner
Terraform module for scalable GitHub action runners on AWS
Terraform module that provisions auto-scaling GitHub Actions self-hosted runners on AWS using spot instances and Lambda functions. When a workflow job queues, a webhook Lambda fires, pushes to SQS, a scale-up Lambda spins EC2 instances, runners register as ephemeral, and a scale-down Lambda terminates them after the job. Aimed at teams hitting GitHub-hosted runner limits or needing access to internal VPC resources.
Ephemeral runners by default mean no shared state between jobs — each runner is a fresh EC2 instance that deregisters itself on completion, which closes the most common self-hosted runner security hole. Spot instance support with on-demand failover (`enable_runner_on_demand_failover_for_errors`) means you get the cost savings without hard job failures when spot capacity dries up. The multi-runner configuration lets you deploy heterogeneous fleets (arm64 for regular builds, beefy x64 for integration tests) from a single Terraform root. Lambda functions run on arm64 Graviton by default — a small but sensible default that saves money on the control plane.
Initial setup is genuinely fiddly: you need a GitHub App (not a PAT), the Lambda ZIPs must be downloaded or built separately before `terraform apply`, and the Getting Started doc is long. The default spot allocation strategy is `lowest-price` rather than `price-capacity-optimized`, which AWS has explicitly said leads to more interruptions — you have to know to override this. Enterprise-level runners are not supported, so large GitHub Enterprise orgs with centralized billing will hit a wall. The dynamic labels feature (`enable_dynamic_labels`) is flagged experimental and warns it can be removed without a major release, but it's the feature most useful for advanced multi-runner setups, so depending on it is a gamble.