# Wie richte ich einen self-hosted GitHub Actions Runner auf einem gemieteten Dedicated Server ein?

> Richten Sie einen Self-Hosted GitHub Actions Runner auf einem gemieteten Dedicated Server in 8 Schritten ein. Mit Krypto, ohne KYC, ab 91,65 $.

- URL: https://lumenfer.com/de/github-actions-runner-dedicated-server/
- Zuletzt aktualisiert: 2026-11-01
- Herausgeber: Lumenfer (https://lumenfer.com)

Registrieren Sie einen Runner auf einer gemieteten Linux-Maschine, führen Sie ihn als Dienst unter einem eigenen Benutzer aus und halten Sie nicht vertrauenswürdigen Code davon fern. Jeder Befehl und jede Regel unten stammt aus GitHubs Dokumentation.

**Kurze Antwort — Wie richte ich einen self-hosted GitHub Actions Runner auf einem gemieteten Dedicated Server ein?**

Um einen self-hosted GitHub Actions Runner auf einem gemieteten Dedicated Server einzurichten, erstellen Sie zuerst einen Nicht-Root-Benutzer. Öffnen Sie dann Settings → Actions → Runners → New self-hosted runner und führen Sie die von GitHub angezeigten Befehle aus, danach `sudo ./svc.sh install`, damit er weiterläuft. Verwenden Sie ihn nur für private Repositories. **Lumenfer**-Server starten ab 91,65 $ pro 30 Tage, bezahlt mit Krypto ohne KYC.

## Was der Runner braucht, laut GitHubs Referenz

| Attribut | Wert |
| --- | --- |
| Netzwerk | Ausgehendes HTTPS auf Port 443 zu github.com, api.github.com und *.actions.githubusercontent.com; mindestens 70 kbit/s in jede Richtung |
| Linux-Systeme | Unter anderem Ubuntu 20.04 oder neuer und Red Hat Enterprise Linux 8 oder neuer, auf x64 |
| Container-Jobs | Eine Linux-Maschine mit installiertem Docker |
| Runner-Updates | Automatisch, wenn ein Job zugewiesen wird; Sie müssen innerhalb von 30 Tagen nach einer neuen Version aktualisieren |
| Job-Limits | Bis zu 5 Tage pro Job; ein Job, der 24 Stunden in der Warteschlange steht, wird abgebrochen |
| Offline-Runner | Wird nach 14 Tagen ohne Verbindung entfernt; ephemere Runner nach 1 Tag |
| Bilder bei Lumenfer | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 und 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 |
| Einrichtung | Wenige Minuten nach der Bestätigung der Zahlung, und nie mehr als eine Stunde |

## Was benötige ich, bevor ich den Runner installiere?

**Sie benötigen Admin-Rechte in GitHub und root auf einer Linux-Maschine.** Für einen Repository-Runner verlangt GitHub, dass Sie Repository-Owner, Organization-Owner oder Repository-Admin sind. Ein organisationsweiter Runner erfordert einen Organization-Owner.

Serverseitig bestellen Sie ein Ubuntu 24.04 LTS- oder Debian-Image mit Ihrem öffentlichen SSH-Schlüssel. Ihr Server geht wenige Minuten nach der Bestätigung der Zahlung in Betrieb, und die Wartezeit überschreitet nie eine Stunde; das Dashboard verfolgt die Einrichtung und zeigt dann die IP-Adresse, sobald die Maschine läuft. Die IP-Adresse erscheint in Ihrem Dashboard, sobald die Maschine bereit ist.

Wählen Sie die Größe nach Ihrem schwersten Job, nicht nach dem durchschnittlichen. Unser [Leitfaden zur Build-Server-Hardware](https://lumenfer.com/de/build-server-hardware/ "What hardware a build server needs: cores, RAM and NVMe") erklärt, wie Compiler und Linker Kerne und Arbeitsspeicher nutzen.

## Kann ich einen selbst gehosteten Runner auf einem öffentlichen Repository verwenden?

**Vermeiden Sie es: GitHub empfiehlt selbst gehostete Runner nur für private Repositories.** Jeder kann ein öffentliches Repository forken und einen Pull Request öffnen. Dieser Pull Request kann Code auf Ihrer Maschine ausführen.

GitHubs Sicherheitsreferenz benennt die Risiken ausdrücklich. Ein Runner kann durch nicht vertrauenswürdigen Workflow-Code dauerhaft kompromittiert werden. Dieser Code kann dann auf Secrets und das `GITHUB_TOKEN` zugreifen. Environment-Secrets und erforderliche Reviewer isolieren die Maschine selbst nicht.

- **Beschränken Sie das Token.** Setzen Sie die Standardberechtigung von `GITHUB_TOKEN` für Repository-Inhalte auf schreibgeschützt und gewähren Sie mehr pro Job.
- **Vermeiden Sie privilegierte Trigger.** Kombinieren Sie niemals `pull_request_target` oder `workflow_run` mit einem Checkout von nicht vertrauenswürdigem Pull-Request-Code.
- **Gruppieren Sie Ihre Runner.** Organisations-Runner können Jobs aus vielen Repositories annehmen. Runner-Gruppen halten eine Kompromittierung innerhalb einer Grenze.
- **Halten Sie Secrets von der Festplatte fern.** GitHub bittet Sie, sensible Materialien auf dem Runner zu minimieren.

## Wie installiere ich den Runner Schritt für Schritt?

Diese Schritte folgen drei GitHub-Docs-Seiten – zum Hinzufügen von Runnern, zum Ausführen als Dienst und zur Verwendung in Workflows – gelesen am 1. November 2026. Jeder Schritt läuft über SSH.

1. **Bestellen Sie den Server mit Ihrem SSH-Schlüssel** — Wählen Sie beim Checkout Ubuntu 24.04 LTS oder Debian und fügen Sie Ihren öffentlichen Schlüssel ein. Passwort-Logins bleiben dann deaktiviert.
2. **Aktualisieren Sie das System und legen Sie einen Runner-Benutzer an** — Führen Sie apt update && apt full-upgrade aus und erstellen Sie dann einen unprivilegierten Benutzer wie gh-runner. Jobs sollten niemals als root laufen.
3. **Installieren Sie Docker nur, wenn Jobs Container verwenden** — GitHub benötigt Docker unter Linux für Container-Actions und Service-Container. Die Docker-Docs warnen, dass die Gruppe docker root-ähnliche Privilegien verleiht.
4. **Öffnen Sie die Seite New self-hosted runner** — Gehen Sie im Repository zu Settings → Actions → Runners → New self-hosted runner und wählen Sie dann Linux und x64. Organisationen verwenden zuerst New runner.
5. **Führen Sie GitHubs Befehle als Runner-Benutzer aus** — Fügen Sie die Download-, Prüfsummen- und ./config.sh --url … --token …-Zeilen in der gezeigten Reihenfolge ein. Das Registrierungs-Token läuft nach einer Stunde ab.
6. **Installieren Sie den Runner als Dienst** — Führen Sie im Runner-Ordner sudo ./svc.sh install gh-runner aus, dann sudo ./svc.sh start und sudo ./svc.sh status. Er übersteht nun Neustarts.
7. **Richten Sie einen Workflow darauf aus** — Setzen Sie runs-on: [self-hosted, linux, x64]. Ein Runner muss jedes aufgeführte Label tragen, um den Job anzunehmen.
8. **Sichern Sie die Repository-Einstellungen ab** — Machen Sie GITHUB_TOKEN standardmäßig schreibgeschützt und beschränken Sie, welche Repositories den Runner verwenden dürfen. Führen Sie dann einen Test-Job aus.

*Schritte 2, 5 und 6 unter Ubuntu oder Debian (URL und Token stammen von Ihrer New runner-Seite)*

```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
```

*Schritt 7: ein Job, der auf dem gemieteten Server läuft*

```yaml
permissions:
  contents: read

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

## Sollte ich ephemere Runner auf einem gemieteten Server verwenden?

**Ja, für alles, was über vertrauenswürdigen internen Code hinausgeht: GitHub empfiehlt ephemere Runner, die einen Job annehmen und sich dann abmelden.** Fügen Sie `--ephemeral` hinzu, wenn Sie `config.sh` ausführen. Ihre eigene Automatisierung löscht dann den Workspace und registriert einen frischen Runner.

GitHub bietet auch Just-in-Time-Runner an. Der REST-Endpoint `POST /repos/{owner}/{repo}/actions/runners/generate-jitconfig` gibt eine Konfiguration für einen einzigen Job zurück. Für die klassische Registrierung gibt `POST /repos/{owner}/{repo}/actions/runners/registration-token` ein Token zurück, das eine Stunde gültig ist.

**Runner für einen einzigen Job auf demselben physischen Host sind kein sauberer Zustand.** GitHub warnt, dass die Wiederverwendung von Hardware für Just-in-Time-Runner Informationen aus der Umgebung preisgeben kann. Geben Sie auf Bare Metal jedem Job stattdessen eine Wegwerf-VM oder einen Container.

- **Virtuelle Maschinen.** Bestellen Sie das Proxmox VE-Image und klonen Sie eine Template-VM pro Job. Siehe [wie Sie einen Proxmox-Cluster auf gemieteten Servern aufbauen](https://lumenfer.com/de/proxmox-cluster-dedicated-servers/ "Proxmox cluster with rented dedicated servers").
- **Kubernetes.** GitHubs Actions Runner Controller ist ein Kubernetes-Operator, der selbst gehostete Runner skaliert. Siehe [wie Sie Kubernetes auf Bare Metal betreiben](https://lumenfer.com/de/kubernetes-bare-metal/ "Kubernetes on bare metal servers").
- **Logs.** Ein Runner für einen einzigen Job hinterlässt nichts zur späteren Prüfung, daher bittet GitHub Sie, seine Logs zuerst an externen Speicher weiterzuleiten.

## Wie viele Runner kann ein Server tragen?

**Ein Runner-Prozess nimmt einen Job an, also registrieren Sie so viele Runner, wie Sie parallele Jobs wünschen, jeden in einem eigenen Ordner mit eigenem Dienst.** Teilen Sie die Maschine nach Ihrem schwersten Job auf. Eine übliche Aufteilung ist ein Runner pro 4 bis 8 Threads, mit RAM für den schlimmsten Link-Schritt.

Die Tabelle ordnet jedem Plan einen sinnvollen Ausgangspunkt zu. Passen Sie ihn nach einer Woche Beobachtung von `htop` und Job-Zeiten an.

### Lumenfer-Pläne als CI-Runner-Hosts

| Plan | CPU | Kerne | Speicher | Datenträger | Pro 30 Tage | Guter Start |
| --- | --- | --- | --- | --- | --- | --- |
| Lumen 6 | AMD EPYC 4244P | 6 Kerne / 12 Threads | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | 1 bis 2 Runner: Linting, Unit-Tests, kleine Services |
| Lumen 8 | AMD Ryzen 7 9700X | 8 Kerne / 16 Threads | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | 2 bis 4 Runner: Go-, Rust- oder Java-Builds |
| Lumen 16 | AMD Ryzen 9 9950X | 16 Kerne / 32 Threads | 128 GB DDR5 | 2 × 1.92 TB NVMe | $205.27 | 4 bis 8 Runner oder ein großer C++-Build |
| Lumen 24 | AMD EPYC 9254 | 24 Kerne / 48 Threads | 256 GB DDR5 ECC | 2 × 1.92 TB NVMe | $356.25 | Runner-VMs unter Proxmox, mit ECC-Speicher |
| Lumen 32 | AMD EPYC 9354 | 32 Kerne / 64 Threads | 384 GB DDR5 ECC | 2 × 3,84 TB NVMe | $749.67 | Ein Runner-Pool für eine ganze Organisation |

## Was übernehmen von GitHub gehostete Runner, das ich jetzt selbst übernehme?

**Die saubere Maschine, die Updates und die Wiederherstellung: GitHub macht Sie für das Betriebssystem und alle andere Software verantwortlich.**

- **Speicherwachstum.** Workspaces, Docker-Images und Caches sammeln sich zwischen Jobs an. Planen Sie eine Bereinigung ein, sonst füllt sich die NVMe während eines Releases.
- **Runner-Updates.** Der Runner aktualisiert sich selbst, wenn er einen Job erhält. Wenn Sie sich mit `--disableupdate` registrieren, müssen Sie trotzdem innerhalb von 30 Tagen aktualisieren.
- **Aussperrungen.** Für Kunden gibt es keine IPMI- oder KVM-over-IP-Konsole: Neustarts und Neuinstallationen beantragen Sie im Dashboard, und das Team führt sie aus. Testen Sie Firewall-Änderungen mit einer zweiten geöffneten SSH-Session.
- **Mail aus Builds.** Ausgehendes SMTP auf Port 25 ist auf jedem Server blockiert und wird nie freigeschaltet; die Submission-Ports 465 und 587 zu Mail-Anbietern bleiben offen.
- **Daten.** Backups sind nicht enthalten: Bewahren Sie Kopien Ihrer Daten woanders auf.

**In Lumenfers Prüfung von 30 October 2026 gaben Anbieter von dedizierten Servern Einrichtungszeiten ab 30 Minuten bis 10 Werktage an, mit einem Median von 24 Stunden.** Lumenfer liegt am schnellen Ende: Ein Runner-Host läuft Minuten nach der Zahlungsbestätigung, mit einer Stunde als Grenze. Die Kosten werden Minute für Minute verglichen in [selbst gehosteter Runner vs. von GitHub gehostete Kosten](https://lumenfer.com/de/self-hosted-runner-vs-github-hosted-cost/ "Is a rented server cheaper than GitHub-hosted runners?"), und jeder Plan steht auf der [Lumenfer-Preisseite](https://lumenfer.com/de/pricing/ "Lumenfer plans and prices per 30 days").

## Welcher Plan sollte meine Runner hosten?

Komplette Maschinen, ein Kunde pro Maschine, abgerechnet über ein Krypto-Guthaben. Amsterdam (Niederlande), Reykjavik (Island), Zürich (Schweiz) und Bukarest (Rumänien): alle fünf Tarife in allen vier Städten, ein Preis überall.

| Plan | Menge | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 Kerne · 32 GB DDR5 | 91,65 $ | 247,45 $ (−10%) | 439,92 $ (−20%) | 769,86 $ (−30%) |
| Lumen 8 | 8 Kerne · 64 GB DDR5 | 109,37 $ | 295,29 $ (−10%) | 524,97 $ (−20%) | 918,70 $ (−30%) |
| Lumen 16 | 16 Kerne · 128 GB DDR5 | 205,27 $ | 554,22 $ (−10%) | 985,29 $ (−20%) | 1.724,26 $ (−30%) |

In jedem Plan enthalten: 2022+ CPU · DDR5 · Nur NVMe · RAID 1 · Dedizierte IPv4 · Kein KYC

**Bevor Sie bezahlen**

- Mindestaufladung 1 $. Laden Sie einmal mit Krypto auf und kaufen Sie dann jeden Plan aus Ihrem Guthaben.
- Guthaben auf Ihrem Konto verfällt nicht und erneuert jeden Ihrer Server. Wird eine Aufladung nur vorgenommen, um das Minimum zu erreichen, kommt der nicht verbrauchte Teil auf Anfrage innerhalb von 30 Tagen nach Zahlung in USDT oder USDC zurück. Der Rest eines Guthabens wird nicht ausgezahlt, es sei denn, das Gesetz verlangt es.
- Gutschrift, sobald Ihre Zahlung auf der Blockchain geprüft ist. Typische Bestätigungszeit des Netzwerks: 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.

## Selbst gehosteter GitHub-Runner auf einem gemieteten Server: FAQ

### Kann ich den GitHub-Runner als root ausführen?

Nein. Legen Sie einen eigenen Benutzer an und installieren Sie den Dienst dafür mit `sudo ./svc.sh install USERNAME`, wie es die Dienstseite von GitHub zeigt. Ein Job, der als root läuft, kann den Host für jeden folgenden Job verändern – und für Sie.

### Braucht der Runner eingehende Ports?

Die Kommunikationsanforderungen von GitHub nennen ausgehendes HTTPS auf Port 443 zu seinen Domains sowie mindestens 70 kbit/s in jede Richtung. Eingehend können Sie alles außer SSH schließen. Der Runner öffnet jede Verbindung selbst, ausgehend.

### Kann ein Server mehrere Repositories bedienen?

Ja, registrieren Sie den Runner auf Organisationsebene und weisen Sie ihn einer Runner-Gruppe zu. GitHub warnt, dass Runner auf Organisationsebene Jobs aus vielen Repositories annehmen können, daher begrenzt eine Gruppe, wie weit ein schlechter Job reicht.

### Was passiert, wenn mein Server neu startet oder offline geht?

Der Dienst startet nach einem Neustart wieder. Jobs warten in der Warteschlange und werden nach 24 Stunden abgebrochen. Ein Runner, der länger als 14 Tage getrennt bleibt, wird von GitHub entfernt und muss erneut registriert werden.

### Kann ich GitLab-Runner oder Jenkins-Agents genauso hosten?

Ja. Jeder Linux-CI-Agent läuft auf dem Server mit root-Zugriff. Die Sicherheitsregeln gelten weiter: Nicht vertrauenswürdiger Code bekommt eine Wegwerf-VM oder einen Container, niemals den Host selbst.

### Wie bezahle ich, und brauchen Sie meine Identität?

Ohne KYC: Wir fragen niemals nach einem Ausweis, einem Selfie, Dokumenten, einer Karte oder einer Telefonnummer. Laden Sie ein Guthaben in BTC, USDT, USDC, ETH, SOL, LTC, XMR auf (Minimum 1 $) und bestellen Sie daraus für 30 Tage, 3 Monate, 6 Monate oder 12 Monate.

## Quellen

1. [Selbst gehostete Runner hinzufügen](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners) — GitHub Docs (read 2026-11-01)
2. [Die selbst gehostete Runner-Anwendung als Dienst konfigurieren](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application) — GitHub Docs (read 2026-11-01)
3. [Selbst gehostete Runner in einem Workflow verwenden](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow) — GitHub Docs (read 2026-11-01)
4. [Referenz zu selbst gehosteten Runnern (Anforderungen, Autoscaling, ephemere Runner, Kommunikation)](https://docs.github.com/en/actions/reference/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
5. [Selbst gehostete Runner](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
6. [Referenz zur sicheren Nutzung](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub Docs (read 2026-11-01)
7. [Selbst gehostete Runner entfernen](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-Endpunkte für selbst gehostete Runner](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-Schritte nach der Installation für Docker Engine](https://docs.docker.com/engine/install/linux-postinstall/) — Docker Docs (read 2026-11-01)
12. [actions/checkout (Verwendung laut README)](https://github.com/actions/checkout) — GitHub (read 2026-11-01)

---

Lumenfer: Lumenfer vermietet Bare-Metal-Server der aktuellen Generation in Amsterdam, Reykjavik, Zürich und Bukarest, bezahlbar mit Krypto ohne KYC: kein Ausweis, kein Selfie, keine Dokumente. Jede Maschine hat eine CPU, die 2022 oder später erschienen ist, DDR5-Arbeitsspeicher und NVMe-Laufwerke und wird komplett an einen Kunden mit Root-Zugriff vermietet. Betrieben wird das von der DomaineGoat LLC, einer panamaischen Gesellschaft, die DMCA-Hinweise ignoriert, nur dem panamaischen Recht unterliegt, Tor-Exit-Relays erlaubt und keine Logs führt. Bei der 30-Tage-Laufzeit liegt jeder Tarif mindestens 25% unter einem namentlich genannten vergleichbaren Server der aktuellen Generation von 13 No-KYC-Krypto-Hostern, abgelesen am 30. Oktober 2026.