terraform-aws-gitlab-runner-fleet¶
A lean OpenTofu module for a GitLab Runner fleeting fleet on AWS: one
always-on manager plus scale-to-zero spot workers (the
docker-autoscaler executor with fleeting-plugin-aws). Purpose-built for the
phpboyscout ops account to replace cattle-ops/gitlab-runner, giving full
control over the levers that module hid: spot allocation strategy (no forced
spot_instance_pools), the workers' Docker install and disk size, an EFS and S3
cache layer, and no plan-time Lambda (so CI can plan and apply in separate jobs).
The design is spec 0015, A hand-rolled terraform-aws-gitlab-runner-fleet
module, in the phpboyscout/infra wiki. That project is private, so it is
named here rather than linked.
Usage¶
module "runner_fleet" {
source = "gitlab.com/phpboyscout/gitlab-runner-fleet/aws"
version = "~> 0.2.0" # pre-1.0, a minor release may break: take patches only
name_prefix = "pbs-ops-runner"
vpc_id = var.vpc_id
subnet_ids = var.subnet_ids
runner_token_ssm_parameter_name = aws_ssm_parameter.runner_token.name
ebs_kms_key_arn = data.aws_kms_key.ebs_default.arn
max_instances = 4 # hard spot-instance ceiling (cost guardrail)
tags = { Project = "phpboyscout", Environment = "ops" }
}
Every input and output, with its default, is in the generated tables in the README.
Further reading¶
The blog carries a curated route through this subject: Infrastructure with AWS and OpenTofu collects everything written about it, ordered so you can start at the beginning rather than newest-first.
Ask phpbotscout

He answers questions about the projects over on the Discord, citing the docs where they already cover it, and offering to raise an issue where they don't. Bring a bug, an idea, or a questionable engineering decision.