GitLab Runner Docker Autoscaler on AWS
Building an autoscaling runner fleet on AWS with the Docker Autoscaler executor and the AWS fleeting plugin on an Auto Scaling group: manager placement, idle capacity and the shared cache in S3.

Choosing, scaling and securing the GitLab Runner fleet that executes CI/CD jobs, from Docker Autoscaler on cloud VMs to the Kubernetes executor.
Building an autoscaling runner fleet on AWS with the Docker Autoscaler executor and the AWS fleeting plugin on an Auto Scaling group: manager placement, idle capacity and the shared cache in S3.
Autoscaling runners on Azure Virtual Machine Scale Sets in Uniform mode and Google Cloud instance groups with GitLab's fleeting plugins, and why the runner manager must not run on a spot VM.
Replacing the deprecated Docker Machine executor before its removal in GitLab 20.0: mapping config.toml settings to the Docker Autoscaler or Instance executor and a parallel cutover by runner tags.
Running CI jobs as pods with the Kubernetes executor: RBAC and service account permissions, resource requests and overwrite limits, helper container sizing and namespace layout per team.
Deploying GitLab Runner on OpenShift with the GitLab Operator: security context constraints, autoscaling within the cluster and keeping runner versions aligned with GitLab.
Switching runner registration from legacy registration tokens to glrt- authentication tokens: creating runners in the UI or API, updating automation and the Helm chart secret, then disabling the legacy workflow.
Configuring a shared S3-compatible cache for autoscaled runners so jobs on fresh instances still restore dependencies, with Shared and Path settings to split or share caches across runners.
When jobs need the whole VM, operating system or attached devices: using the autoscaling Instance executor instead of Docker, and how it compares with Docker Autoscaler for isolation and cost.
Self-managed runners for .NET, Windows and Apple platform builds: installing GitLab Runner on Windows and macOS as services, executor choices and isolating desktop toolchains from shared Linux fleets.
Autoscaling on-premises runners by cloning vSphere templates with the community fleeting plugin, what it means that GitLab does not test community plugins, and a support plan for it.
Splitting instance, group and project runners by trust level, tagging for workload types, protected-branch-only runners for deployments and isolating untrusted projects from privileged jobs.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.