Faster builds on dedicated cores and NVMe

Think in job slots: decide how many threads a typical job needs, then divide the server. As an estimate, assuming 8 threads per job:

The lower slot count keeps a few threads for the host, the runner agent and caches. Compile-heavy jobs scale with threads; test suites are often limited by a single thread or by I/O, so profile your slowest pipeline stage before buying cores. Use the spare RAM: building in a tmpfs directory takes disk I/O off the critical path for many compile jobs.

Prefer ephemeral runners that start a fresh container or microVM for each job and discard it afterwards, for example with actions-runner-controller on Kubernetes or GitLab Runner's Docker executor. Each job gets a clean environment, while caches live outside the job sandbox.

On a dedicated runner, the biggest wins usually come from never downloading or rebuilding the same thing twice:

• Container images: a pull-through registry mirror (Distribution or Harbor) on the private network, and BuildKit's cache on local NVMe.
• Dependencies: proxy npm, PyPI, Maven and Go module downloads through a local cache.
• Compilers: ccache or sccache for C, C++ and Rust, and a Bazel remote cache on NVMe for monorepos.
• Git: keep mirrors or reference clones on the runner and use shallow or partial clones.

On a Pro 64, use a small mirrored partition for the OS and stripe the rest of the four NVMe Gen5 drives as RAID 0 for cache data, which can always be rebuilt. Traffic is unmetered on every port, so warming caches, pushing artifacts and mirroring registries cost nothing extra. Share caches between runners in the same location over a free private VLAN.

A self-hosted runner executes whatever code a pipeline hands it, so treat it as exposed infrastructure:

• No untrusted code on persistent runners: GitHub's documentation recommends self-hosted runners only for private repositories, because a pull request from a fork can run arbitrary code on the machine. For public projects, use ephemeral runners or keep fork builds on hosted runners.
• Separate trust levels: dedicated runners, or at least separate runner groups, for deploy jobs that hold production credentials.
• Short-lived credentials: OIDC federation or scoped tokens instead of long-lived secrets stored on the host.
• A hardened host: SSH keys only, a default-deny firewall and automatic security updates; our server hardening guide covers the basics.

Keep runner hosts reproducible. With the REST API and the Terraform provider you can reinstall a runner from a clean image on a schedule, and the KVM console gets you back in if a bad change locks you out.