First steps on a Ryzen 9 9950X CI machine

Your Ryzen 9 9950X machine runs Ubuntu 24.04 LTS unless you chose another image. It is a dedicated CI machine: 16 cores and 32 threads that only your jobs use, with a disk that keeps its caches between jobs. This guide registers it as a self-hosted runner and sets up Docker and caching.

Prepare the machine

Install updates, then create a user for the runner so jobs don't run as root:

apt update && apt full-upgrade -y
adduser --disabled-password --gecos "" runner

Install Docker

Most CI jobs build or run containers. Install Docker Engine by following Docker's guide for Ubuntu, then let the runner user use it:

usermod -aG docker runner

GitHub Actions runner

1. In GitHub, open your repository or organization, then Settings → Actions → Runners → New self-hosted runner, and choose Linux and x64.
2. GitHub shows commands to download the runner and a registration token. Run them as the runner user (su - runner), in a directory such as ~/actions-runner. Add a label you can target, for example --labels 9950x on the ./config.sh line.
3. Install it as a service so it starts on boot. As root, in the runner's directory: ./svc.sh install runner then ./svc.sh start.

Then target it from a workflow:

jobs:
  build:
    runs-on: [self-hosted, linux, x64, 9950x]

GitHub's guide to adding self-hosted runners has the details, including organization-wide runners and runner groups.

More than one job at a time

One runner takes one job at a time. To use more of the 32 threads, register several runners, each in its own directory with its own name, and install each as a service. Two to four runners suit most compile and test workloads; watch htop during a busy run and adjust.

GitLab runner

1. Install GitLab Runner from GitLab's package repository, following GitLab's Linux install guide.
2. In GitLab, create a runner under Settings → CI/CD → Runners for a project (or under your group). GitLab shows a runner authentication token starting with glrt-.
3. Register it with the Docker executor:

gitlab-runner register --non-interactive \
  --url https://gitlab.com \
  --token glrt-<your-token> \
  --executor docker \
  --docker-image alpine:latest

Use your own GitLab URL if you self-host. To run several jobs at once, raise concurrent at the top of /etc/gitlab-runner/config.toml. GitLab's registration guide covers the other executors and options.

Caching

A dedicated machine keeps its disk between jobs, which is most of its speed advantage over hosted runners. Make use of it:

• Docker layers. Image layers and BuildKit cache stay on the machine, so unchanged layers aren't rebuilt or pulled again.
• Language caches. Package caches (Go modules and build cache, npm, pip, Cargo, Gradle) stay in the runner user's home directory between jobs. Point your tools there instead of uploading and downloading a cache each run.
• Hosted cache actions. actions/cache stores caches on GitHub's servers, so every save and restore crosses the network. A local cache is usually faster on a dedicated machine.
• Disk space. Caches grow. Check with df -h and docker system df, and prune on a schedule, for example a weekly cron job running docker system prune -af --filter "until=168h".
• Extra drives. If you ordered a storage add-on, it's a good home for caches and Docker's data directory.