# How do I set up a self-hosted GitHub Actions runner on a rented dedicated server?

> Set up a self-hosted GitHub Actions runner on a rented dedicated server in 8 steps from GitHub's own docs. Crypto, no KYC, from $91.65.

- URL: https://lumenfer.com/github-actions-runner-dedicated-server/
- Last updated: 2026-11-01
- Publisher: Lumenfer (https://lumenfer.com)

Register a runner on a rented Linux machine, run it as a service under its own user, and keep untrusted code away from it. Every command and rule below comes from GitHub's documentation.

**Quick answer — How do I set up a self-hosted GitHub Actions runner on a rented dedicated server?**

To set up a self-hosted GitHub Actions runner on a rented dedicated server, create a non-root user first. Then open Settings → Actions → Runners → New self-hosted runner and run the commands GitHub prints, then `sudo ./svc.sh install` to keep it running. Use it on private repositories only. **Lumenfer** servers start at $91.65 per 30 days, paid in crypto with no KYC.

## What the runner needs, per GitHub's reference

| Attribute | Value |
| --- | --- |
| Network | Outbound HTTPS on port 443 to github.com, api.github.com and *.actions.githubusercontent.com; at least 70 kbit/s each way |
| Linux systems | Ubuntu 20.04 or later and Red Hat Enterprise Linux 8 or later, among others, on x64 |
| Container jobs | A Linux machine with Docker installed |
| Runner updates | Automatic when a job is assigned; you must update within 30 days of a new release |
| Job limits | Up to 5 days per job; a job queued for 24 hours is cancelled |
| Offline runners | Removed after 14 days without connecting; ephemeral runners after 1 day |
| Images at Lumenfer | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 and Proxmox VE 9 |
| Login | You log in as root over SSH. Paste a public key when ordering and password logins stay disabled, or skip it and receive a temporary root password with the server, to replace on your first login |
| Setup | A few minutes after the payment confirms, and never past the one-hour mark |

## What do I need before installing the runner?

**You need admin rights in GitHub and root on a Linux machine.** For a repository runner, GitHub asks you to be the repository owner, an organization owner, or a repository admin. An organization-wide runner needs an organization owner.

On the server side, order an Ubuntu 24.04 LTS or Debian image with your SSH public key. Your server goes live a few minutes after the payment confirms, and the wait never runs past one hour; the dashboard follows the build, then shows the IP address once the machine is up. The IP address appears in your dashboard when the machine is ready.

Pick the size from your heaviest job, not your average one. Our [build server hardware guide](https://lumenfer.com/build-server-hardware/ "What hardware a build server needs: cores, RAM and NVMe") explains how compilers and linkers use cores and memory.

## Can I use a self-hosted runner on a public repository?

**Avoid it: GitHub recommends self-hosted runners for private repositories only.** Anyone can fork a public repository and open a pull request. That pull request can run code on your machine.

GitHub's security reference spells out the stakes. A runner can be persistently compromised by untrusted workflow code. That code can then reach secrets and the `GITHUB_TOKEN`. Environment secrets and required reviewers do not isolate the machine itself.

- **Restrict the token.** Set the default `GITHUB_TOKEN` permission to read-only for repository contents, and grant more per job.
- **Avoid privileged triggers.** Never combine `pull_request_target` or `workflow_run` with a checkout of untrusted pull-request code.
- **Group your runners.** Organization runners can take jobs from many repositories. Runner groups keep a compromise inside one boundary.
- **Keep secrets off the disk.** GitHub asks you to minimise sensitive material stored on the runner.

## How do I install the runner, step by step?

These steps follow three GitHub Docs pages, on adding runners, running them as a service and using them in workflows, read on 1 November 2026. Each one runs over SSH.

1. **Order the server with your SSH key** — Choose Ubuntu 24.04 LTS or Debian at checkout and paste your public key. Password logins then stay disabled.
2. **Update the system and add a runner user** — Run apt update && apt full-upgrade, then create an unprivileged user such as gh-runner. Jobs should never run as root.
3. **Install Docker only if jobs use containers** — GitHub needs Docker on Linux for container actions and service containers. Docker's docs warn that the docker group grants root-level privileges.
4. **Open the New self-hosted runner page** — In the repository, go to Settings → Actions → Runners → New self-hosted runner, then pick Linux and x64. Organizations use New runner first.
5. **Run GitHub's commands as the runner user** — Paste the download, checksum and ./config.sh --url … --token … lines in the order shown. The registration token expires after one hour.
6. **Install the runner as a service** — From the runner folder, run sudo ./svc.sh install gh-runner, then sudo ./svc.sh start and sudo ./svc.sh status. It now survives reboots.
7. **Point a workflow at it** — Set runs-on: [self-hosted, linux, x64]. A runner must carry every listed label to take the job.
8. **Lock down the repository settings** — Make the GITHUB_TOKEN read-only by default and limit which repositories may use the runner. Then run a test job.

*Steps 2, 5 and 6 on Ubuntu or Debian (URL and token come from your New runner page)*

```bash
# step 2, as root: update and create the runner user
apt update && apt full-upgrade -y
adduser --disabled-password --gecos "" gh-runner

# step 5, as gh-runner, in the folder where you ran GitHub's download lines
./config.sh --url https://github.com/OWNER/REPO --token TOKEN
# for a runner that takes one job, then de-registers:
# ./config.sh --url https://github.com/OWNER/REPO --token TOKEN --ephemeral

# step 6, from the same folder, with sudo rights
sudo ./svc.sh install gh-runner
sudo ./svc.sh start
sudo ./svc.sh status
```

*Step 7: a job that runs on the rented server*

```yaml
permissions:
  contents: read

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v7
      - run: make -j"$(nproc)" test
```

## Should I use ephemeral runners on one rented server?

**Yes, for anything beyond trusted internal code: GitHub recommends ephemeral runners, which take one job and then de-register.** Add `--ephemeral` when you run `config.sh`. Your own automation then wipes the workspace and registers a fresh runner.

GitHub also offers just-in-time runners. The REST endpoint `POST /repos/{owner}/{repo}/actions/runners/generate-jitconfig` returns a one-job configuration. For classic registration, `POST /repos/{owner}/{repo}/actions/runners/registration-token` returns a token valid for one hour.

**One-job runners on the same physical host are not a clean slate.** GitHub warns that re-using hardware for just-in-time runners can expose information from the environment. On bare metal, give each job a throwaway virtual machine or container instead.

- **Virtual machines.** Order the Proxmox VE image and clone a template VM per job. See [how to build a Proxmox cluster on rented servers](https://lumenfer.com/proxmox-cluster-dedicated-servers/ "Proxmox cluster with rented dedicated servers").
- **Kubernetes.** GitHub's Actions Runner Controller is a Kubernetes operator that scales self-hosted runners. See [how to run Kubernetes on bare metal](https://lumenfer.com/kubernetes-bare-metal/ "Kubernetes on bare metal servers").
- **Logs.** A one-job runner leaves nothing to inspect later, so GitHub asks you to forward its logs to external storage first.

## How many runners can one server carry?

**One runner process takes one job, so register as many runners as you want parallel jobs, each in its own folder with its own service.** Divide the machine by your heaviest job. A common split is one runner per 4 to 8 threads, with RAM for the worst link step.

The table maps each plan to a sensible starting point. Adjust after a week of watching `htop` and job times.

### Lumenfer plans as CI runner hosts

| Plan | CPU | Cores | Memory | Disks | Per 30 days | Good start |
| --- | --- | --- | --- | --- | --- | --- |
| Lumen 6 | AMD EPYC 4244P | 6 cores / 12 threads | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | 1 to 2 runners: lint, unit tests, small services |
| Lumen 8 | AMD Ryzen 7 9700X | 8 cores / 16 threads | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | 2 to 4 runners: Go, Rust or Java builds |
| Lumen 16 | AMD Ryzen 9 9950X | 16 cores / 32 threads | 128 GB DDR5 | 2 × 1.92 TB NVMe | $205.27 | 4 to 8 runners, or one large C++ build |
| Lumen 24 | AMD EPYC 9254 | 24 cores / 48 threads | 256 GB DDR5 ECC | 2 × 1.92 TB NVMe | $356.25 | Runner VMs under Proxmox, with ECC memory |
| Lumen 32 | AMD EPYC 9354 | 32 cores / 64 threads | 384 GB DDR5 ECC | 2 × 3.84 TB NVMe | $749.67 | A runner pool for a whole organization |

## What do GitHub-hosted runners handle that I now handle myself?

**The clean machine, the updates and the recovery: GitHub makes you responsible for the operating system and all other software.**

- **Disk growth.** Workspaces, Docker images and caches pile up between jobs. Schedule a cleanup, or the NVMe fills during a release.
- **Runner updates.** The runner updates itself when it gets a job. If you register with `--disableupdate`, you must still update within 30 days.
- **Lock-outs.** There is no IPMI or KVM-over-IP console for customers: you request reboots and reinstalls in the dashboard and the team performs them. Test firewall changes with a second SSH session open.
- **Mail from builds.** Outbound SMTP on port 25 is blocked on every server and is never unblocked; submission ports 465 and 587 to mail providers remain open.
- **Data.** Backups are not included: keep copies of your data somewhere else.

**In Lumenfer's check of 30 October 2026, dedicated-server sellers stated setup times from 30 minutes to 10 business days, with a median of 24 hours.** Lumenfer sits at the fast end: a runner host is live minutes after the payment confirms, with one hour as the limit. Costs are compared minute by minute in [self-hosted runner vs GitHub-hosted cost](https://lumenfer.com/self-hosted-runner-vs-github-hosted-cost/ "Is a rented server cheaper than GitHub-hosted runners?"), and every plan is on the [Lumenfer pricing page](https://lumenfer.com/pricing/ "Lumenfer plans and prices per 30 days").

## Which plan should host my runners?

Whole machines, one customer each, billed from a crypto balance. Amsterdam (Netherlands), Reykjavik (Iceland), Zurich (Switzerland) and Bucharest (Romania): all five plans in all four cities, one price everywhere.

| Plan | Quantity | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 cores · 32 GB DDR5 | $91.65 | $247.45 (−10%) | $439.92 (−20%) | $769.86 (−30%) |
| Lumen 8 | 8 cores · 64 GB DDR5 | $109.37 | $295.29 (−10%) | $524.97 (−20%) | $918.70 (−30%) |
| Lumen 16 | 16 cores · 128 GB DDR5 | $205.27 | $554.22 (−10%) | $985.29 (−20%) | $1,724.26 (−30%) |

In every plan: 2022+ CPU · DDR5 · NVMe only · RAID 1 · Dedicated IPv4 · No KYC

**Before you pay**

- Minimum top-up $1. Top up once in crypto, then buy any plan from your balance.
- Credit on your balance does not expire and renews any of your servers. When a top-up is only made to reach the minimum, the unspent part comes back on request within 30 days of payment, in USDT or USDC. The rest of a balance is not paid out unless the law requires it.
- Credited once your payment is checked on the blockchain. Typical network confirmation time: BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min · XMR ≈ 20 min

## Self-hosted GitHub runner on a rented server: FAQ

### Can I run the GitHub runner as root?

Do not. Create a dedicated user and install the service for it with `sudo ./svc.sh install USERNAME`, as GitHub's service page shows. A job running as root can change the host for every job after it, and for you.

### Does the runner need any inbound ports?

GitHub's communication requirements list outbound HTTPS on port 443 to its domains, plus at least 70 kbit/s each way. Inbound, you can close everything except SSH. The runner opens every connection itself, outbound.

### Can one server serve several repositories?

Yes, register the runner at organization level and assign it to a runner group. GitHub warns that organization runners can take jobs from many repositories, so a group limits how far a bad job reaches.

### What happens if my server reboots or goes offline?

The service starts again after a reboot. Jobs wait in the queue and are cancelled after 24 hours. A runner that stays disconnected for more than 14 days is removed from GitHub and must be registered again.

### Can I host GitLab runners or Jenkins agents the same way?

Yes. Any Linux CI agent runs on the server with root access. The security rules carry over: untrusted code gets a throwaway VM or container, never the host itself.

### How do I pay, and do you need my identity?

No KYC: we never ask for an ID, a selfie, documents, a card or a phone number. Top up a balance in BTC, USDT, USDC, ETH, SOL, LTC, XMR (minimum $1) and order from it for 30 days, 3 months, 6 months or 12 months.

## Sources

1. [Adding self-hosted runners](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners) — GitHub Docs (read 2026-11-01)
2. [Configuring the self-hosted runner application as a service](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application) — GitHub Docs (read 2026-11-01)
3. [Using self-hosted runners in a workflow](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow) — GitHub Docs (read 2026-11-01)
4. [Self-hosted runners reference (requirements, autoscaling, ephemeral runners, communication)](https://docs.github.com/en/actions/reference/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
5. [Self-hosted runners](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
6. [Secure use reference](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub Docs (read 2026-11-01)
7. [Removing self-hosted runners](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/remove-runners) — GitHub Docs (read 2026-11-01)
8. [Actions limits](https://docs.github.com/en/actions/reference/limits) — GitHub Docs (read 2026-11-01)
9. [REST API endpoints for self-hosted runners](https://docs.github.com/en/rest/actions/self-hosted-runners) — GitHub Docs (read 2026-11-01)
10. [Actions Runner Controller](https://docs.github.com/en/actions/concepts/runners/actions-runner-controller) — GitHub Docs (read 2026-11-01)
11. [Linux post-installation steps for Docker Engine](https://docs.docker.com/engine/install/linux-postinstall/) — Docker Docs (read 2026-11-01)
12. [actions/checkout (README usage)](https://github.com/actions/checkout) — GitHub (read 2026-11-01)

---

Lumenfer: Lumenfer rents current-generation bare-metal servers in Amsterdam, Reykjavik, Zurich and Bucharest, paid in crypto with no KYC: no ID, no selfie, no documents. Every machine has a CPU launched in 2022 or later, DDR5 memory and NVMe drives, and is rented whole by one customer with root access. It is run by DomaineGoat LLC, a Panama company that ignores DMCA notices, answers only to Panamanian law, allows Tor exit relays and keeps no logs. On the 30-day term, every plan is priced at least 25% under a named comparable current-generation server from 13 no-KYC crypto hosts, read on 30 October 2026.