Selbstgehostete GitHub Actions Runner, in der EU
Dieselben Workflows, auf einer Maschine in Prag oder Covilhã, die Ihnen für den Monat gehört statt pro Minute - mit noch warmem Build-Cache und einer Adresse, die eine Firewall tatsächlich freigeben kann.
Für wen es ist
Ein Team, das den Minutenzähler beobachtet
Eine Linux-Minute mit 2 Kernen kostet 0,006 USD, eine mit 16 Kernen 0,042 USD - der Matrix-Build, der die Suite schnell gemacht hat, ist genau das, was die Rechnung interessant gemacht hat.
Ein Workflow, der etwas Privates erreichen muss
Der Deploy-Schritt muss mit einer Datenbank, einer Registry oder einer Appliance sprechen, die nur bekannte Adressen akzeptiert - und gehostete GitHub-Runner kommen aus einem Bereich, der zu groß zum Freigeben ist.
Ein Build, der mehr braucht, als das Image mitbringt
Ein lizenzierter Compiler, ein Emulator, ein 30 GB großes Fixture-Set oder schlicht mehr Platte, als der gehostete Runner hat - und es bei jedem Job erneut zu installieren ist der größte Teil der Pipeline.
Was sich ändert, wenn der Runner Ihnen gehört
- Workspace und Caches bleiben zwischen den Jobs bestehen, sodass das Wiederherstellen der Abhängigkeiten aufhört, der längste Schritt im Workflow zu sein.
- Eine statische IPv4 aus AS204057, die Ihre Datenbank, Registry oder VPN per Adresse freigeben kann.
- Was Sie installieren, bleibt installiert - Toolchains, lizenzierte SDKs, Emulatoren, große Fixture-Sets, alles, was das gehostete Image nicht mitbringt.
- Runner auf Repository-, Organisations- oder Enterprise-Ebene registriert, mit Labels Ihrer Wahl und einem Workflow, der sie über runs-on auswählt.
- Platte und RAM nach Ihrer Wahl statt der festen Form, in der ein gehosteter Runner kommt.
- Eine Maschine in Prag oder Covilhã unter einem zyprischen Vertrag - das ist eine Antwort zur Datenresidenz und nicht eine Regionseinstellung.
Nach dem dimensioniert, was die Pipeline tatsächlich tut
Ein Runner-Dienst ist ein Job zur Zeit, Parallelität ist hier also eine Anzahl von Runner-Prozessen und keine Tarifstufe - mehrere auf einem Host, jeder in seinem eigenen Verzeichnis, ist die übliche Form. Dimensionieren Sie nach dem schwersten Job statt nach dem Durchschnitt und lassen Sie Luft auf der Platte: Workspace, Tool-Cache und Container-Layer liegen alle dort, und genau diese Beständigkeit ist der Grund, überhaupt selbst zu hosten. Die ehrliche Hälfte des Handels: ein fester Monats-Host kostet in einer Woche ohne Pushes dasselbe, gehostete Minuten kosten dann nichts. Es rechnet sich, sobald die Pipeline an den meisten Tagen läuft.
Einen GitHub Actions Runner auf einem frischen Host installieren
Linux x64, in der Reihenfolge, die GitHub dokumentiert. Das Registrierungstoken wird pro Runner erzeugt und verfällt eine Stunde nach dem Öffnen der Seite - holen Sie es also zuletzt.
-
Einen unprivilegierten Benutzer dafür anlegen
sudo adduser --disabled-password --gecos "" runner sudo -iu runnerDer Runner führt aus, was ein Workflow ihm sagt, also sollte er nicht root sein und sich sein Home mit nichts anderem teilen. Alles Weitere läuft als dieser Benutzer.
-
Den Runner herunterladen und entpacken
mkdir actions-runner && cd actions-runner curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c tar xzf ./actions-runner-linux-x64-2.336.0.tar.gzDiese Version und diese Prüfsumme sind die mit Release v2.336.0 veröffentlichten. Sehen Sie vor dem Kopieren auf der Release-Seite nach einer neueren: der Runner aktualisiert sich danach selbst, aber der erste Download gehört Ihnen zum Prüfen.
-
Gegen ein Repository oder eine Organisation konfigurieren
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,euDas Token holen Sie unter Settings, dann Actions, dann Runners, dann New self-hosted runner - es ist zeitlich begrenzt und verfällt eine Stunde nach der Ausgabe. Richten Sie die URL auf die Organisation statt auf das Repository, um einen Runner über mehrere Repositories zu teilen.
-
Als Dienst laufen lassen
sudo ./svc.sh install runner sudo ./svc.sh start sudo ./svc.sh statussvc.sh nimmt den Benutzer entgegen, unter dem der Dienst laufen soll - deshalb wurde der Benutzer runner zuerst angelegt. Nehmen Sie stattdessen ./run.sh, wenn Sie erst einen Job landen sehen wollen, bevor Sie sich auf einen Dienst festlegen.
-
needrestart daran hindern, Jobs mitten im Lauf abzuschießen
echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.confUnter Debian und Ubuntu startet needrestart Dienste neu, deren Bibliotheken aktualisiert wurden - auch einen Runner mitten im Job. GitHub dokumentiert genau diese Datei als den Weg, ihn auszunehmen.
-
Einen Workflow darauf richten
name: smoke on: [push] jobs: build: runs-on: [self-hosted, linux, x64, eu] steps: - uses: actions/checkout@v6 - run: cat /etc/os-releaseruns-on trifft auf jedes Label in der Liste zu, ein Job mit vier Labels landet also nur auf einem Runner, der alle vier trägt. Bleibt er in der Warteschlange, fehlt ein Label - und ein Job, der länger als 24 Stunden wartet, schlägt fehl.
Geprüft anhand der offiziellen Dokumentation am 2026-08-15 — Quelle lesen
Was wir nicht sind
- Wir sind nicht GitHub. GitHub, GitHub Actions und der Runner gehören ihnen, und nichts auf dieser Seite ist von ihnen unterstützt. Wir verkaufen die Maschine, auf der der Runner läuft.
- Das ersetzt Ihren GitHub-Tarif nicht. Selbstgehostete Runner kosten keine Actions-Minuten, darum geht es ja, aber Lizenzplätze, Speicher und alles Weitere bleiben auf deren Rechnung.
- Wir verwalten den Runner nicht, sofern Sie nicht danach fragen. Sie installieren ihn, oder Sie buchen unsere Administration dazu und wir halten ihn gepatcht, registriert und im Blick.
- Selbstgehostete Runner sind für öffentliche Repositories dokumentiert schlecht geeignet: ein Fork kann eine Workflow-Änderung vorschlagen, und die liefe auf Ihrer Maschine. Halten Sie sie auf privaten Repositories, sofern Sie das nicht durchdacht haben.
- Es gibt hier keine Autoscaling-Steuerungsebene. Wenn Sie Runner pro Job erzeugen und zerstören wollen, ist das der Actions Runner Controller auf einem Kubernetes-Cluster - den wir gern hosten, auf einer anderen Seite.
Die Teile, die Teams zu spät entdecken
- Ein Runner-Dienst führt einen Job zur Zeit aus. Parallelität entsteht dadurch, mehrere zu installieren, jeden in eigenem Verzeichnis mit eigenem Dienst, nicht durch eine Einstellung.
- Das Registrierungstoken verfällt eine Stunde nach der Ausgabe - erzeugen Sie es also, wenn Sie bereit sind, config.sh auszuführen, und nicht zu Beginn des Nachmittags.
- Labels sind der gesamte Routing-Mechanismus. runs-on trifft auf jedes Label der Liste zu, ein Tippfehler wirft also keinen Fehler - der Job wartet einfach und schlägt nach 24 Stunden in der Warteschlange fehl.
- Der Runner braucht lttng-ust, OpenSSL, Kerberos, zlib und libicu. Debian und Ubuntu bringen sie mit; ein minimales Container-Image oft nicht.
- x64 und ARM64 werden unter Linux unterstützt, ARM32 nur unter Linux. Debian ab 10 und Ubuntu ab 20.04 sind die dokumentierten Grundlagen.
- Alles, was der Workflow zurücklässt, bleibt auf der Platte - das ist das Feature, und es ist zugleich der Grund, warum ein selbstgehosteter Runner einen geplanten Aufräum-Job und einen Snapshot will.
Gehostete CI-Minuten gegen einen eigenen Runner
| Gehostete CI-Minuten des Anbieters | Ein Runner bei DCXV | |
|---|---|---|
| Wofür Sie zahlen | Jede Minute jedes Jobs, so lange das Projekt existiert | Ein fester Monats-Host, was die Pipeline in dem Monat auch tut |
| Ein Build, der langsamer wird | Kostet jeden Monat mehr, in dem er langsam bleibt | Kostet nichts extra - die Maschine ist bereits bezahlt |
| Docker-Layer-Cache | Bei jedem Job kalt, sofern Sie ihn nicht selbst hoch- und herunterladen | Warm auf lokalem NVMe, zwischen Jobs und zwischen Tagen |
| Parallelität | Eine Tarifstufe, die Sie hochbuchen | Eine Zahl, die Sie in Ihrer eigenen Konfigurationsdatei setzen |
| Wo der Checkout landet | Eine geteilte Flotte, oft in einer Region, die Sie nicht festlegen können | Eine Maschine in Prag oder Covilhã, unter einem zyprischen Vertrag |
| Ausgehende Adresse | Ein großer geteilter Bereich, den nichts freigeben kann | Eine statische IPv4 aus AS204057, Ihre zum Freigeben |
| Was die Maschine tragen kann | Was das Runner-Image zufällig mitbringt | Jede Toolchain, Lizenz oder jedes Fixture-Set, das Sie einmal installieren |
So kommt das auf Ihrem Host in Gang
Sagen Sie, was die Pipeline tut
Der schwerste Job, den Sie heute fahren, wie viele davon gleichzeitig laufen sollen und ob Container-Images gebaut werden. Das reicht, um einen Host ohne Raten zu dimensionieren.
Wir übergeben die Maschine
Prag oder Covilhã, Root-Zugang und eine statische IPv4, in unter zehn Minuten. Bringen Sie Ihr eigenes Image mit, wenn der Runner schon darin steckt.
Folgen Sie der Anleitung auf dieser Seite
Es ist die Abfolge des Herstellers, aus dessen aktueller Dokumentation genommen statt aus einem Blogbeitrag, und sie dauert auf einem sauberen Host wenige Minuten.
Snapshot machen, dann den zweiten dazunehmen
Machen Sie einen Snapshot, sobald die erste Pipeline grün ist - dann ist die nächste Maschine eine Wiederherstellung statt eines Neuaufbaus. Ein Pool wächst durch weitere Hosts, nicht dadurch, einen riesig zu machen.
Warum uns wählen
- Tier-III-zertifizierte Einrichtungen, 99,982 % Facility-SLA
- Eigenes Netz, AS204057, IPv4 und IPv6 Dual-Stack
- Support 24/7/365 mit rund 10 Minuten durchschnittlicher Reaktionszeit
- Zyprische Gesellschaft, EU-Gerichtsbarkeit, DSGVO-konform seit 2007
FAQ
- Was kosten gehostete GitHub-Runner im Vergleich zum Selbsthosten?
GitHub rechnet gehostete Linux-Runner pro Minute ab: 0,006 USD für 2 Kerne, 0,012 für 4 Kerne, 0,022 für 8 Kerne und 0,042 für 16 Kerne, Windows bei 0,010 für 2 Kerne und macOS bei 0,062 für eine Maschine mit 3 oder 4 Kernen. Selbstgehostete Runner verbrauchen keine Actions-Minuten. Ein Host hier beginnt bei 16,49 EUR im Monat, was ungefähr 2.700 Minuten auf einem gehosteten 2-Kern-Runner entspricht - der Umschlagpunkt liegt also bei etwa 45 Stunden Build-Zeit im Monat
- Wie richte ich einen selbstgehosteten GitHub Actions Runner ein?
Legen Sie einen unprivilegierten Benutzer an, laden Sie das Runner-Archiv für linux-x64 aus den Releases von actions/runner herunter und prüfen Sie die Prüfsumme, führen Sie ./config.sh mit Ihrer Repository- oder Organisations-URL und dem Registrierungstoken aus Settings, Actions, Runners aus und installieren Sie ihn dann mit sudo ./svc.sh install als Dienst und starten Sie ihn. Die genauen Befehle stehen auf dieser Seite. Das Registrierungstoken verfällt eine Stunde nach der Ausgabe
- Wie viele Jobs kann ein Runner gleichzeitig ausführen?
Einen. Ein Runner-Dienst nimmt einen einzelnen Job zur Zeit, Parallelität heißt also, mehrere Runner-Dienste auf dem Host zu installieren, jeden in eigenem Verzeichnis. Deshalb zählt die Dimensionierung auf dieser Seite Runner-Dienste statt Jobs, und deshalb trägt eine Maschine mit 8 vCPU bequem einen kleinen Matrix-Build
- Welche Betriebssysteme und Architekturen werden unterstützt?
Unter Linux Debian ab 10, Ubuntu ab 20.04, RHEL ab 8, CentOS ab 8, Fedora ab 29, openSUSE ab 15.2 und deren Verwandte, auf x64, ARM64 und ARM32. Der Runner braucht außerdem lttng-ust, OpenSSL, Kerberos, zlib und libicu, die Debian und Ubuntu standardmäßig mitbringen
- Ist ein selbstgehosteter Runner für ein öffentliches Repository sicher?
GitHub rät davon ab, und der Grund ist konkret: jeder kann einen Pull Request öffnen, der die Workflow-Datei ändert, und dieser geänderte Workflow liefe auf Ihrer Maschine. Halten Sie selbstgehostete Runner auf privaten Repositories, sofern Sie das nicht durchgelesen und echte Isolation eingerichtet haben. Alles, was ein Job zurücklässt, bleibt zudem auf der Platte - ein Vorteil fürs Caching und ein Risiko für Geheimnisse
- Kann ein Runner mehrere Repositories bedienen?
Ja. Registrieren Sie ihn auf Organisationsebene statt auf Repository-Ebene, dann kann jedes Repository der Organisation ihn auswählen und die Arbeit über Labels in runs-on lenken. Ein Job, der ein Label verlangt, das kein Runner trägt, wartet einfach und schlägt nach 24 Stunden in der Warteschlange fehl - so sieht ein Tippfehler in runs-on aus
Wenn Sie Hilfe benötigen oder zusätzliche Fragen haben, wenden Sie sich bitte an die Manager oder schreiben Sie an das Support-Team unter support@dcxv.com
Bereit anzufangen?
Monatliche Abrechnung, keine Einrichtungsgebühr, keine Bindung