Run CI jobs on a self-hosted runner

A self-hosted runner moves build and test jobs onto a server you control. This is useful when jobs need special packages, stable caches, access to a private network, or more predictable resources than a shared runner provides.

When a dedicated runner fits

Use one for trusted private repositories, internal deployment jobs, container builds, or projects with large dependencies. GitHub recommends avoiding persistent self-hosted runners for public repositories because untrusted workflow code can compromise the machine.

Keep the runner away from production applications and databases. Anyone who can change an allowed workflow may be able to execute commands and read credentials available to its jobs.

Choosing a server size

XS or Small may be enough for linting and lightweight tests. Compilation, Docker builds, parallel jobs, and large caches benefit from Medium or Large. Measure job time, queue time, memory pressure, and free disk space. Compare the VPS plans before choosing a size.

What you manage

You control repository access, runner updates, installed tools, credentials, cache cleanup, and isolation between jobs. Short-lived deployment credentials and ephemeral runners reduce the impact of a compromised job.

The GitHub Actions runner guide covers a complete installation for a trusted private repository on Ubuntu 26.04.