Self-hosted runner
Your own machine running CI jobs instead of one supplied by GitHub or GitLab, useful for private networks, special hardware, or more control.
What it is
A self-hosted runner is a machine you operate that executes CI jobs for a hosted system such as GitHub Actions. Instead of borrowing a vendor's fresh virtual machine, you install the runner agent on your server, VM, or workstation and route matching jobs to it with labels.
Reach for one when builds need private-network access, unusual hardware, licensed software, very large machines, or a warm local cache that would be expensive to recreate on every job. You take responsibility for patching, capacity, isolation, logs, and cleaning up whatever jobs leave behind.
Gotcha: a long-lived runner remembers things. A malicious or careless job can read another job's files, poison a cache, or use credentials available to the host. Prefer an ephemeral runner that handles one job and is then destroyed, and never run untrusted fork code on a machine that can reach production.
Ask AI for it
Set up an ephemeral GitHub Actions self-hosted runner on a dedicated Linux VM. Register it with the official actions runner using the --ephemeral flag and the labels self-hosted, linux, x64, and internal, then target those exact labels in runs-on. Give the runner a one-job lifecycle, a non-root service account, no inbound network ports, and only the outbound access the build requires. Use a short-lived registration token, wipe the work directory after the job, and block workflows from forks from using this runner.