CI on autoscaling runners: GitLab CI or GitHub Actions, x86 and ARM
When you need it
Builds wait in the queue for hours, static runners are configured by hand and fill up, artifact storage overflows and the cost of CI is opaque. Or you are moving from one CI to another and want to get it right from the start.
What you get
Runner fleets on AWS scaled to the queue, x86 and ARM separately, spot where builds tolerate it, defined as code and deployed through GitOps. Build cache and artifacts in object storage with retention. For GitHub Actions: OIDC to AWS instead of static keys. A single deploy flow across repositories. For self-hosted GitLab: a server upgrade procedure with background-migration checks, CI history retention, image retention policies in ECR. A migration plan with a test week on real jobs and a staged retirement of the old runners.
Typical duration
Fleets and migration of the first project: 3–5 weeks. Full retirement of old runners depends on the number of projects, usually 6–10 weeks. Estimate after a first call.
Contact
- E-mail:
- LinkedIn: linkedin.com/in/devops24x7
- Telegram: t.me/devops24x7
- Time zone: CET (Munich)