Alle Produkte 
VPS für Entwicklung und CI/CD: Worauf es ankommt
Ein eigener Server für Builds und Tests lohnt sich, sobald die kostenlosen Minuten in GitHub Actions oder GitLab CI nicht mehr reichen. Ein eigener Runner hat kein Zeitlimit, und auf ihm bleiben die Caches für Abhängigkeiten und Docker-Images erhalten – wiederholte Builds laufen dadurch um ein Vielfaches schneller. Denselben VPS können Sie bequem auch als entfernte Entwicklungsumgebung oder Testsystem nutzen.
Kerne und Arbeitsspeicher: viel, aber nur kurz
Kompilieren, Frontend-Builds und Testläufe verteilen sich auf die Kerne, daher ist die Kernzahl für einen Runner wichtiger als für einen Webserver. Richtwerte:
- 2 Kerne und 4 GB – kleine Projekte mit Node.js, Python oder PHP, Linter und Unit-Tests;
- 4 Kerne und 8 GB – Docker-Images bauen, Frontend mit Webpack oder Vite, Integrationstests mit Datenbank;
- 8 Kerne und 16 GB – Kompilieren von Go, Rust, Java oder C++, Android-Builds, parallele Jobs.
Bei wenigen Builds pro Tag steht der Server die meiste Zeit still. Hier hilft die stundenweise Abrechnung: Ein leistungsstarker Server wird für die Arbeitszeit gestartet und danach gelöscht, und Sie zahlen nur die Stunden. Viele Anbieter erlauben das per API, sodass sich der Runner automatisch starten lässt.
Festplatte: Caches belegen mehr, als man denkt
Docker-Images, die Caches von npm, pip, Maven oder Gradle und Build-Artefakte belegen schnell Dutzende Gigabyte. Nehmen Sie NVMe ab 50–80 GB und richten Sie eine Bereinigung ein: docker system prune per Zeitplan und eine begrenzte Aufbewahrungsdauer für Artefakte. Die Festplattengeschwindigkeit bestimmt direkt, wie lange die Installation der Abhängigkeiten dauert – auf einer langsamen Festplatte kann sie länger brauchen als der Build selbst.
So binden Sie einen Runner an
- GitHub Actions – der Self-hosted Runner wird mit einem Befehl aus den Einstellungen des Repositorys oder der Organisation installiert und läuft als Dienst.
- GitLab CI –
gitlab-runnermit Docker-Executor: Jeder Job läuft in einem sauberen Container, und die Images werden auf dem Server gecacht. - Gitea, Forgejo, Woodpecker, Drone – schlanke Alternativen, wenn Sie auch das Repository selbst auf Ihrem Server hosten; siehe auch VPS für GitLab.
Virtualisierung und Sicherheit
Für Docker-Builds brauchen Sie KVM: Bei Container-Virtualisierung startet Docker oft nicht oder läuft nur eingeschränkt (mehr dazu auf der Seite VPS für Docker). Verbinden Sie einen Self-hosted Runner nicht mit öffentlichen Repositorys: Ein fremder Pull Request kann sonst beliebigen Code auf Ihrem Server ausführen. Übergeben Sie Secrets über CI-Variablen, statt sie auf der Festplatte zu speichern, und aktualisieren Sie den Runner zusammen mit dem System.
Wo platzieren?
Ein Server nahe an Ihrem Git-Hosting und Ihrer Image-Registry lädt Abhängigkeiten schneller herunter. Für GitHub und Docker Hub eignen sich Server in Europa und den USA; ein lokaler Mirror oder Pull-Through-Cache für Registrys beschleunigt Builds zusätzlich und macht sie unabhängig von Limits externer Dienste.