VPS für selbstgehostete CI/CD-Runner
Gehostete CI-Minuten werden gemessen, in Warteschlangen gestellt und starten langsam. Ein VeloxMedia VPS verwandelt jedes CI-System in einen dauerhaften Runner, den Sie kontrollieren: Installieren Sie Docker und Ihren Runner-Agent einmal, halten Sie Build-Caches zwischen Jobs warm und zahlen Sie einen pauschalen Monatspreis statt Mehrkosten pro Minute.
Jeder Server wird mit vollem Root-Zugriff, NVMe-SSD-Speicher, unbegrenztem Datenvolumen und einer dedizierten IPv4 geliefert. Registrieren Sie einen GitLab Runner, einen selbstgehosteten GitHub-Actions-Runner, einen Jenkins-Agent, Drone, Woodpecker oder einen Buildkite-Agent und richten Sie dann Ihre Pipelines auf Hardware aus, die Sie kontrollieren. Die Bereitstellung ist in etwa 60 Sekunden abgeschlossen, und die Neuinstallation mit einem Klick versetzt einen Runner in einen sauberen Zustand, wann immer eine Build-Umgebung driftet.
Da der Transfer unbegrenzt ist, lösen das Ziehen von Basis-Images, das Installieren von Abhängigkeiten und das Pushen von Artefakten niemals Egress-Gebühren aus. Geclusterte Hochverfügbarkeit hält Runner bei Hardware-Ausfällen online, und Live-Migration ohne Ausfallzeit verschiebt Workloads während der Host-Wartung, sodass lange Builds nicht unterbrochen werden.
- Pauschaler Monatspreis ab $5 ohne Build-Gebühren pro Minute und ohne Einrichtungsgebühren
- NVMe-SSD-Speicher für schnelle Wiederherstellung von Abhängigkeiten und Docker-Layer-Caching
- Unbegrenztes Datenvolumen für Image-Pulls und Artefakt-Uploads
- Voller Root-Zugriff zum Installieren von Docker und jedem selbstgehosteten Runner-Agent
- Bereitstellung in 60 Sekunden und Neuinstallation mit einem Klick für saubere, reproduzierbare Runner
- Dedizierte IPv4, um Runner in privaten Registrys und Deploy-Zielen auf die Zulassungsliste zu setzen
Warum eigene CI/CD-Runner auf einem VPS betreiben
Gehostete Runner rechnen pro Minute ab und begrenzen die Parallelität in Tarifen, die Sie nicht kontrollieren. Ein dedizierter VPS dreht dieses Modell um. Sie zahlen einen festen Monatspreis ohne Gebühren pro Minute und ohne Einrichtungsgebühren, sodass eine stark ausgelastete Pipeline dasselbe kostet wie eine ruhige. Der Runner bleibt zwischen Jobs online, was bedeutet, dass Abhängigkeits-Caches, Docker-Layer und geklonte Repositorys bereits auf der Festplatte liegen, wenn der nächste Build startet. Sie entscheiden über die Toolchain, die Parallelität und die Runner-Tags, und nichts wird hinter einer Nutzungsstufe gedrosselt.
Schnellere Builds auf NVMe mit unbegrenztem Datentransfer
Die meiste CI-Zeit fließt in das Installieren von Abhängigkeiten, das Wiederherstellen von Caches und das Ziehen von Container-Images. NVMe-SSD-Speicher reduziert diesen Overhead: npm-, pip-, cargo-, go-mod- und Maven-Caches werden schnell wiederhergestellt, Docker-Layer-Caching liest und schreibt mit NVMe-Geschwindigkeit, und Checkouts großer Monorepos bleiben schnell. Unbegrenztes Datenvolumen bedeutet, dass das ständige Ziehen von Basis-Images und Pushen von Build-Artefakten keine Bandbreitenrechnung verursacht. Unter jedem Server liegt verteilter, replizierter NVMe-Speicher, sodass zwischengespeicherte Daten gegen den Ausfall einer einzelnen Festplatte oder eines Hosts geschützt sind.
Voller Root für Docker, Container und jeden Runner-Agent
Sie erhalten vollen Root- oder Administratorzugriff auf jedem Server, sodass Sie Docker, Podman, buildx, Sprach-Toolchains und den Runner-Agent Ihrer Wahl installieren können. Registrieren Sie einen GitLab Runner mit Docker- oder Shell-Executor, einen selbstgehosteten GitHub-Actions-Runner, einen Jenkins-Agent oder Drone-, Woodpecker- und Buildkite-Agents. Wählen Sie aus Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, CentOS oder Alpine, und nehmen Sie Windows Server, wenn Sie .NET, MSVC oder andere Windows-Ziele bauen müssen. Die browserbasierte Konsole bietet Ihnen VNC-, SSH- und RDP-Zugriff direkt aus dem Portal, falls Sie sich jemals mitten in der Konfiguration aussperren.
Saubere, reproduzierbare Runner, die Sie in Sekunden zurücksetzen können
Build-Hygiene ist wichtig, wenn Jobs sich einen Host teilen. Neuinstallation und Rebuild mit einem Klick versetzen einen Runner in etwa 60 Sekunden in ein sauberes Betriebssystem zurück, sodass Sie eine Maschine wiederverwenden können, die Zustand angesammelt hat. Snapshots erfassen einen vollständig konfigurierten Golden Runner und lassen Sie ihn wiederherstellen oder das Setup auf einen neuen Server klonen. Backups und der Rescue-Modus stellen einen Host wieder her, der nicht bootet, und die Schwachstellenüberwachung meldet ungepatchte Pakete, bevor sie in einen Build gelangen. Eine dedizierte IPv4 plus Firewall-Regeln lassen Sie den Runner in einer privaten Registry, einem Artefaktspeicher oder einem Produktions-Deploy-Ziel auf die Zulassungsliste setzen, und Reverse DNS ist über das Panel bearbeitbar.
Passen Sie einen Tarif an Ihre Pipeline an und platzieren Sie ihn nahe Ihrem Code
Sechs einheitliche Tarife skalieren von leichten bis zu anspruchsvollen Pipelines. Micro (1 vCPU / 2 GB / 20 GB) und Small (2 / 4 / 40) eignen sich für Linting und einzelne kleine Builds. Medium (4 / 8 / 80) ist ein solider Allzweck-Container-Runner. Plus (4 / 12 / 120) ergänzt Arbeitsspeicher für JVM-Builds, große node_modules-Bäume und Integrationssuiten, während Pro (6 / 16 / 160) und Max (8 / 32 / 200) parallele Matrix-Jobs und große Monorepos bewältigen. Betreiben Sie einen größeren Tarif oder fügen Sie weitere Runner-Instanzen hinzu, wenn die Last wächst. Stellen Sie in London, Amsterdam, US East (Ohio) oder US West (California) bereit, wobei Warsaw, Montreal und Utah in Kürze folgen, sodass ein Runner nah an Ihrem Git-Host und Ihren Deploy-Zielen sitzt. Die Preise beginnen bei $5 pro Monat, Amsterdam ab $6, wobei die jährliche Abrechnung zwei Monate kostenlos bietet. Jede Bereitstellung, Neuinstallation und jeder Snapshot findet im Kundenportal statt, unterstützt durch sichere gehostete Kartenzahlung und 24/7-Support.
VPS für selbstgehostete CI/CD-Runner Fragen
Welche CI/CD-Systeme kann ich auf diesen VPS-Runnern betreiben?
Jedes CI-System, das selbstgehostete Runner oder Agents unterstützt. Gängige Optionen sind GitLab Runner, selbstgehostete GitHub-Actions-Runner, Jenkins-Agents sowie Drone-, Woodpecker- oder Buildkite-Agents. Sie haben vollen Root-Zugriff, um den Agent, Docker und Ihre Toolchain auf Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, CentOS, Alpine oder Windows Server zu installieren.
Welche VPS-Größe benötige ich für einen CI/CD-Runner?
Das hängt von Ihren Builds ab. Small (2 vCPU / 4 GB) bewältigt eine einzelne leichtgewichtige Pipeline, Medium (4 / 8) ist ein guter Allzweck-Container-Runner, und Plus (4 / 12) eignet sich für speicherintensive JVM- oder Integrations-Builds. Pro (6 / 16) und Max (8 / 32) führen parallele Matrix-Jobs und große Monorepos aus. Wenn die Last wächst, wechseln Sie zu einem größeren Tarif oder stellen Sie weitere Runner-Instanzen bereit.
Wie halte ich Build-Umgebungen zwischen Jobs sauber?
Führen Sie jeden Job zur Isolierung in einem Container aus und nutzen Sie Neuinstallation oder Rebuild mit einem Klick, um den gesamten Runner in etwa 60 Sekunden auf ein sauberes Betriebssystem zurückzusetzen. Snapshots lassen Sie einen konfigurierten Golden Runner speichern und bei Bedarf wiederherstellen, während Backups und der Rescue-Modus einen Host wiederherstellen, der nicht bootet.
Zählen das Ziehen von Images und das Pushen von Artefakten gegen ein Bandbreitenlimit?
Nein. Jeder Server umfasst unbegrenztes Datenvolumen, sodass das Ziehen von Basis-Images, das Wiederherstellen von Caches und das Hochladen von Build-Artefakten keine Egress-Gebühren pro GB verursachen. Jeder Server wird zudem mit einer dedizierten IPv4 geliefert, die Sie in einer privaten Registry oder Firewall auf die Zulassungsliste setzen können.
Stellen Sie Ihren ersten Server in unter einer Minute bereit
Wählen Sie eine Region, wählen Sie eine Größe und verbinden Sie sich über SSH. Keine Einrichtungsgebühren, jederzeit kündbar.