GitLab Runner and CI/CD infrastructure

Choosing, scaling and securing the GitLab Runner fleet that executes CI/CD jobs, from Docker Autoscaler on cloud VMs to the Kubernetes executor.

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.

GitLab Runner Kubernetes executor setup

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.

GitLab Runner on Red Hat OpenShift

Deploying GitLab Runner on OpenShift with the GitLab Operator: security context constraints, autoscaling within the cluster and keeping runner versions aligned with GitLab.

Moving GitLab runners to authentication tokens

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.

GitLab runners for Windows and macOS builds

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.

GitLab Runner autoscaling on VMware vSphere

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.

Talk to our team.

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.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.