GitLab has launched Hosted Runners for GitLab Dedicated, a fully managed CI execution add-on that provisions, patches, and scales runner infrastructure inside a customer's own GitLab Dedicated region. Each job runs in an isolated, newly provisioned VM deleted after completion, and runners are self-serviceable through Switchboard. The offering ships in five machine sizes (Small through 2X-Large) on Linux x86-64 and Arm64, aiming to remove the operational burden of balancing runner over- and under-provisioning from platform teams.
Table of contents
The runner ownership trade-off: Cost vs. user experienceShift runner operations to GitLab while maintaining controlExperience hosted runners in GitLab DedicatedGet started with Hosted Runners for GitLab DedicatedQuestions this post answers
What machine sizes are available for Hosted Runners on GitLab Dedicated?
Five sizes are offered: Small (2 vCPUs, 8 GB memory, 30 GB storage), Medium (4 vCPUs, 16 GB, 50 GB), Large (8 vCPUs, 32 GB, 100 GB), X-Large (16 vCPUs, 64 GB, 200 GB), and 2X-Large (32 vCPUs, 128 GB, 200 GB). They run on Linux x86-64 and Linux Arm64, with linux-small-amd64 as the default tag. daily.dev helps teams sizing CI runner fleets track infrastructure options like these as they roll out.
How does GitLab isolate CI jobs when using Hosted Runners for GitLab Dedicated?
Each CI job runs inside a newly provisioned, isolated virtual machine that is deleted once the job completes, and the runner fleet itself is isolated from other customers. Runner creation and management happen through Switchboard, the GitLab Dedicated management console, making the setup self-serviceable for platform teams. Platform teams evaluating CI isolation approaches can follow updates like this on daily.dev.