How do I run a self-hosted GitHub Actions runner on a VPS?

Provision a Linux VPS (Small — 4 vCPU / 4 GB — is the sensible default), install the runner package from your repo's Settings → Actions → Runners, register it with the token GitHub gives you, and start it as a service. Full copy-paste steps are below; you get root in about a minute.

Can I run the runner in Docker?

Yes. Run the official runner image (or your own) in a container, or use it to give each job an isolated, disposable environment. A dedicated-IP plan isn't required — the runner only makes outbound connections to GitHub, so a NAT plan works too.

How do I keep the runner running as a service?

The runner ships with a svc.sh helper that installs a systemd unit: ./svc.sh install && ./svc.sh start. It then survives reboots and restarts on failure. The guide below shows the exact commands.

Is a self-hosted runner cheaper than GitHub-hosted minutes?

For heavy or frequent CI, yes. GitHub-hosted runners bill per minute beyond the free tier; a $8/mo VPS runs unlimited minutes for a flat fee, and stays warm (no cold-start, cached dependencies). One busy repo usually pays for the box.

Do you ask for ID or a credit card?

No. Register with an email, pay with USDC or USDT. No documents, no card, no KYC — ever.

VPS for self-hosted GitHub Actions runners

Run your own self-hosted GitHub Actions runner on a VPS — faster CI, no per-minute billing, full control over the build environment. Crypto payment, no KYC. From $8/mo.

GitHub-hosted runners are convenient until the bill or the wait time starts to hurt. Past the free tier you pay per minute, cold-start every job, and re-download dependencies each run. A self-hosted runner on your own VPS flips all three: flat monthly cost, a warm machine with your caches already on disk, and a build environment you fully control — specific tool versions, more RAM, Docker layer cache that actually persists.

A runner only needs to reach GitHub outbound, so it works on our cheapest plans, pays in crypto, and needs no KYC.

What a runner needs

CPU and RAM for your builds. Small ($8/mo — 4 vCPU, 4 GB RAM, 35 GB NVMe) is the comfortable default for most CI: Node/Go/Rust builds, test suites, Docker image builds. Heavy compilation or parallel jobs? Step up to Medium or a Pro plan.
NVMe disk for caches. The whole point of self-hosting is persistence — dependency caches, Docker layers, build artifacts stay on disk between runs. NVMe keeps restores fast.
No dedicated IP required. The runner dials out to GitHub over HTTPS; nothing needs to reach it inbound. A NAT plan (from $3/mo) is enough. Take a dedicated IP only if you also self-host something that serves traffic.

Set up a runner (Ubuntu 24.04)

Create the runner in your repo (or org): Settings → Actions → Runners → New self-hosted runner → Linux. GitHub shows a download command and a one-time registration token. On the VPS:

# as a non-root user (the runner refuses to run as root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# register with the URL + token from the GitHub UI
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Keep it running as a service

Don't run ./run.sh in a terminal — install it as a systemd service so it survives reboots:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

The runner now appears as Idle in the GitHub UI and picks up any job that targets it.

Use it from a workflow

Point a job at your runner with runs-on:

jobs:
  build:
    runs-on: self-hosted        # or a custom label you set at registration
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Docker-based jobs

Install Docker once and your workflows can build images or run service containers, with layer cache persisting between runs:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # let the runner use Docker without sudo

For throwaway per-job isolation, run the runner itself inside a container and recreate it each run — a common pattern for untrusted or matrix builds.

Why EQVPS for CI

Flat cost, unlimited minutes. No per-minute metering — a busy pipeline costs the same as an idle one.
Warm caches. Dependencies and Docker layers stay on NVMe between runs; builds get faster, not slower.
Root in ~60 seconds, clean images. Ubuntu, Debian and more via cloud-init; install exactly the toolchain you need.
No KYC, crypto payment. Email to sign up, USDC/USDT to pay. Spin up extra runners for release crunches and cancel them after — unused paid time is refunded to your balance.

Full step-by-step setup guide →