GitLab Runner Hosting, auf einer Maschine, die Ihnen gehört
Ein selbstverwalteter Runner in Prag oder Covilhã, dem die ganze Platte allein gehört. So ist der Docker-Layer-Cache bei der zweiten Pipeline des Tages noch da, und die Rechnung bewegt sich nicht, wenn der Build es tut.
Für wen es ist
Ein Team, das Compute-Minuten kauft
Die Testsuite ist gewachsen, also wurde die Pipeline länger, also stieg die Rechnung - und der einzige Hebel, den der Tarif anbietet, ist der Kauf von noch mehr genau derselben Minuten.
Eine Pipeline, die dieselbe Maschine zweimal will
Jeder Job startet auf einer leeren Platte. Das Base-Image wird erneut gezogen, die Abhängigkeiten werden erneut geholt, und das Hochladen des Cache dauert länger als der Schritt, den er sparen sollte.
Ein Repository unter einer Residency-Vorgabe
Quellcode, Artefakte und Deploy-Keys laufen alle durch den Runner, und "eine geteilte Flotte, irgendwo" ist die Antwort, die Ihr Auditor immer wieder rot einkreist.
Was ein selbstverwalteter Runner Ihnen zurückgibt
- Ein warmer Docker-Layer-Cache auf lokalem NVMe, damit die zweite Pipeline des Tages dort anfängt, wo die erste aufgehört hat, statt auf einer leeren Platte.
- Jeder Executor, den Sie wollen - docker, shell, docker-autoscaler, instance oder kubernetes - pro Runner gewählt statt vom Tarif zugeteilt.
- Ihre eigene Parallelität, als Zahl in der config.toml gesetzt statt als nächsthöhere Stufe gekauft.
- Privileged Mode, wenn Sie Docker-in-Docker wirklich brauchen - was Ihnen keine geteilte Flotte je geben wird.
- Eine statische ausgehende IPv4 aus AS204057, damit ein Deploy-Ziel, ein Paketspiegel oder eine Datenbank-Firewall den Runner per Adresse freigeben kann.
- Was der Build wirklich auf dem Host braucht: eine alte Toolchain, ein lizenziertes SDK oder ein Fixture-Set, das niemand einmal pro Job herunterladen möchte.
Nach dem dimensioniert, was die Pipeline tatsächlich tut
GitLab veröffentlicht keine Hardware-Anforderung für den Runner selbst, und das ist kein Versehen: der Runner-Prozess ist klein, der Build ist es nicht. Die Zahl, die zählt, ist der Job. Gehen Sie vom schwersten Job aus, den Sie heute fahren, multiplizieren Sie mit der gewünschten Parallelität und seien Sie großzügig mit der Platte - Layer-Cache und Build-Workspace füllen sie, und eine volle Platte lässt eine Pipeline so scheitern, dass es wie ein kaputter Test aussieht. Eines tut ein fester Monatspreis nicht: in einer ruhigen Woche verschwinden. Gehostete Minuten kosten nichts, wenn niemand pusht, das hier kostet dasselbe. Es rechnet sich ab dem Punkt, an dem die Pipeline an den meisten Tagen läuft.
GitLab Runner auf einem frischen Host installieren
Debian oder Ubuntu, von einem sauberen Server, in der Reihenfolge, die GitLab dokumentiert. Alles unten ist ihre Abfolge, nicht unsere.
-
Das offizielle Paket-Repository hinzufügen
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab liefert das Repository als Setup-Skript aus und bittet darum, es vor der Ausführung zu lesen - deshalb lädt die eigene Anleitung es erst herunter, statt es direkt in eine Shell zu pipen.
-
Den Runner installieren
sudo apt install gitlab-runnerDas Paket legt einen Systembenutzer gitlab-runner an, dessen Home-Verzeichnis leer und ohne Skeleton-Dateien erzeugt wird. Zum Festnageln einer Version installieren Sie gitlab-runner und gitlab-runner-helper-images gemeinsam in derselben Version - seit 17.7.1 gehören sie zusammen, und nur eines zu nennen scheitert an einem Abhängigkeitsfehler.
-
Docker installieren, falls die Jobs in Containern laufen
sudo apt install docker.io sudo systemctl enable --now dockerDer docker-Executor spricht über API v1.25 mit einer lokalen Docker Engine, der Daemon muss also auf dem Runner-Host selbst liegen. Das Distributionspaket reicht für den Anfang; Dockers eigenes Repository führt die neueren Releases, falls ein Build eines braucht.
-
Den Runner registrieren
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Legen Sie den Runner zuerst in GitLab an, unter Settings, dann CI/CD, dann Runners - er gibt ein Authentifizierungstoken zurück, das mit glrt- beginnt und in --token gehört. Job-Tags und die Option für untagged Jobs setzen Sie in genau diesem Formular: bei Authentifizierungstoken gehören sie zum Runner, nicht zum register-Befehl. Der ältere Weg über --registration-token ist veraltet und für die Entfernung in GitLab 20.0 vorgesehen.
-
Parallelität setzen und starten
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusDie config.toml liegt in /etc/gitlab-runner, wenn der Runner als root läuft. concurrent ist eine Obergrenze über alle auf diesem Host registrierten Runner hinweg, keine Einstellung pro Runner, und jeder Runner kann darunter ein eigenes, kleineres Limit tragen.
-
Mit einem Job beweisen
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Committen Sie das als .gitlab-ci.yml, pushen Sie, und der Job sollte binnen weniger Sekunden auf Ihrem Host landen. Bleibt er in der Warteschlange, passen die Tags nicht zu denen, die Sie in der UI gesetzt haben, oder der Runner ist an ein anderes Projekt gebunden.
Geprüft anhand der offiziellen Dokumentation am 2026-08-15 — Quelle lesen
Was wir nicht sind
- Wir sind nicht GitLab. GitLab, GitLab CI/CD und GitLab Runner gehören ihnen, und nichts auf dieser Seite ist von ihnen unterstützt. Was wir verkaufen, ist die Maschine, auf der ein Runner läuft.
- Auf dieser Seite geht es nicht darum, GitLab selbst zu hosten. Eine selbstverwaltete GitLab-Instanz ist eine größere Kiste und ein anderes Gespräch - fragen Sie, und wir dimensionieren eine, aber sie ist nicht das, was hier bepreist ist.
- Wir schreiben Ihre .gitlab-ci.yml nicht. Die Pipeline gehört Ihnen; der Host, das Netz und die Adresse gehören uns.
- Der Runner wird nicht für Sie verwaltet, sofern Sie nicht danach fragen. Sie installieren ihn, oder Sie buchen unsere Administration dazu und wir halten ihn gepatcht, registriert und überwacht.
- Ihr GitLab-Abonnement bleibt bei GitLab. Ein selbstverwalteter Runner verbraucht deren Compute-Minuten nicht, darum geht es ja, aber er ersetzt auch die Lizenzplätze nicht.
Die Teile, die Teams zu spät entdecken
- Der Weg über das Registration-Token verschwindet. Ein in der UI angelegter Runner gibt ein glrt- Authentifizierungstoken zurück, das gitlab-runner register als --token annimmt, und --registration-token ist für die Entfernung in GitLab 20.0 vorgesehen.
- Die Tags sind mitgezogen. Bei einem Authentifizierungstoken gehören Job-Tags, die Untagged-Option und die Bindung zum Runner-Objekt, das Sie in der UI angelegt haben - die Flags, die das früher auf der Kommandozeile setzten, entscheiden nichts mehr.
- Eine Version festnageln heißt zwei Pakete festnageln. Seit 17.7.1 braucht eine explizite gitlab-runner-Version auch gitlab-runner-helper-images in derselben Version, sonst verweigert apt die Installation.
- check_interval steht standardmäßig auf 3 Sekunden. Auf einem Host mit vielen registrierten Runnern ist das eine Menge Polling; erhöhen Sie es, bevor Sie das Netz beschuldigen.
- Docker-in-Docker braucht Privileged Mode, was dem Job faktisch root auf dem Host gibt. Wenn die Pipeline nur Images baut, ist ein rootless Builder wie Kaniko oder Buildah der günstigere Handel.
- Artefakte und Caches wandern weiterhin zu GitLab, sofern Sie den Cache nicht auf Ihren eigenen S3-kompatiblen Bucket richten. Auf einem Runner, den Sie bewusst in die EU verlegt haben, ist das meist der letzte Hop, der noch umzuziehen ist.
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 ist der Unterschied zwischen einem Shared Runner und einem selbstverwalteten?
Ein Shared Runner ist GitLabs Maschine, und Sie zahlen für die Minuten, die sie an Ihrem Job verbringt. Ein selbstverwalteter Runner ist Ihre Maschine: Sie installieren gitlab-runner darauf, registrieren ihn an Ihrem Projekt, Ihrer Gruppe oder Instanz, und er verbraucht überhaupt keine Compute-Minuten. Namespaces auf der kostenlosen Stufe von GitLab erhalten 400 Compute-Minuten im Monat, und eine belebte Pipeline geht in Tagen durch sie hindurch
- Wie installiere und registriere ich GitLab Runner?
Fügen Sie deren apt-Repository über das Setup-Skript von packages.gitlab.com hinzu, installieren Sie das Paket gitlab-runner und führen Sie dann gitlab-runner register nicht-interaktiv mit dem Authentifizierungstoken aus, das GitLab beim Anlegen des Runners in der UI ausgibt. Die vollständige Abfolge mit den genauen Befehlen steht auf dieser Seite, aus deren Dokumentation genommen und nicht aus einem Blogbeitrag
- Registriert man einen Runner noch mit dem Registration-Token?
Nein, und genau diese Änderung macht die meisten älteren Anleitungen kaputt. Legen Sie den Runner zuerst in der GitLab-UI an, dann gibt sie ein Authentifizierungstoken zurück, das mit glrt- beginnt und das gitlab-runner register als --token annimmt. Der alte Weg über --registration-token ist veraltet und für die Entfernung in GitLab 20.0 vorgesehen. Job-Tags, die Untagged-Option und die Bindung gehören jetzt zum Runner-Objekt, das Sie in der UI angelegt haben, nicht zum register-Befehl
- Welche Servergröße braucht ein GitLab Runner?
GitLab veröffentlicht keine Hardware-Anforderung für den Runner selbst, weil der Runner-Prozess klein ist und Ihr Build es nicht ist. Dimensionieren Sie nach dem schwersten Job mal der gewünschten Parallelität. In der Praxis tragen 4 vCPU, 8 GB und 120 GB NVMe zwei bis drei Jobs gleichzeitig; 8 vCPU, 16 GB und 240 GB tragen sechs bis acht. Seien Sie großzügig mit der Platte - Docker-Layer-Cache und Workspace füllen sie
- Brauche ich Docker auf dem Runner-Host?
Nur wenn Sie den docker-Executor nutzen, was die meisten tun. Er spricht über API v1.25 mit einer lokalen Docker Engine, der Daemon muss also auf dem Runner-Host selbst installiert sein. Der shell-Executor braucht überhaupt kein Docker, und die Executoren instance und docker-autoscaler erzeugen Maschinen anderswo
- Können sich mehrere Runner einen Host teilen?
Ja, und das ist die übliche Form. Registrieren Sie so viele, wie Sie wollen, an derselben Installation; die Einstellung concurrent in /etc/gitlab-runner/config.toml ist eine Obergrenze über alle hinweg, und jeder Runner kann darunter ein eigenes, kleineres Limit tragen. Achten Sie auf check_interval, das standardmäßig auf 3 Sekunden steht und viel Polling wird, sobald ein Host ein Dutzend Runner trägt
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