Günstig & schnell
GitHub-Actions-Runner
Unbegrenzt zum Festpreis

Ja, die meisten. Skipbox führt die Workflows öffentlicher und privater Repositorys in GitHub-Organisationen und persönlichen Konten aus. Die VM ist Ubuntu 24.04 auf x64 mit Docker, git, build-essential, Node 22 und Python 3.12, und der Job läuft als Benutzer mit sudo ohne Passwort, wie auf den Runnern von GitHub. Das ubuntu-latest-Image von GitHub hat mehr vorinstalliert, also füge für andere Tools actions/setup-java, actions/setup-go und Ähnliches hinzu.

Seit KI immer mehr Code schreibt, läuft CI jeden Monat öfter, und Minutenabrechnung wächst mit jedem Lauf. Deshalb hat Skipbox bewusst ein anderes Modell gewählt: Du mietest eine VM nur für dein Konto, monatsweise. GitHub berechnet keine Minuten für selbstgehostete Runner, also bleibt der Preis für S pauschal bei $39 im Monat, egal wie viele Jobs du ausführst. Fluxenic, das Unternehmen hinter Skipbox, betreibt Server günstiger Cloud-Anbieter und eigene Server und stellt sie als VMs in sinnvoller Größe bereit. Skipbox übernimmt die mühsame Arbeit für dich: Es registriert die Runner, räumt nach jedem Job auf und prüft den Zustand der Maschine. Außerdem baut es eine defekte Maschine neu auf und hält das Image aktuell. Bei voller Auslastung beträgt der Preis 1/12 des Preises von GitHub und 1/8 des Preises von Blacksmith.

Weil die Maschine nur deinem Konto gehört und zwischen den Jobs weiterläuft. Docker-Layer und Paket-Caches deines letzten Jobs liegen noch auf ihrer Festplatte, also muss ein Build, der sie nutzt, sie weder herunterladen noch neu bauen. Ein von GitHub gehosteter Job startet jedes Mal auf einer neuen VM mit leerer Festplatte. Schon S behält seine Caches auf einer eigenen 80-GB-Festplatte. Das ist mehr als 7x der Cache, den GitHub einem Repository standardmäßig gibt, und nichts davon läuft nach 7 Tagen ohne Nutzung ab. S hat außerdem 4 vCPU, mehr als die 2 Kerne von ubuntu-latest in einem privaten Repository.

Auch wenn du bei einem großen Anbieter einen VPS gleicher Größe mietest, bekommst du keinen selbstgehosteten Runner, der günstiger, schneller und weniger Arbeit ist als Skipbox. Skipbox registriert für jeden Job einen frischen Runner und entfernt ihn danach. Nach jedem Job löscht es die Zugangsdaten des Runners und behält deinen Checkout und die Build-Ausgabe für den nächsten Job. Es prüft den Zustand der Maschine, baut sie neu auf, wenn die Prüfung fehlschlägt, und hält das Image aktuell. Code von Personen ohne Schreibzugriff (etwa Pull Requests aus Forks) läuft auf einer Wegwerf-VM. All das bekommst du für $39 im Monat mit S, indem du eine runs-on-Zeile änderst, ohne etwas warten zu müssen.

Ja, öffentliche und private Repositorys gleichermaßen. Code von Personen ohne Schreibzugriff (etwa Pull Requests aus Forks) läuft auf einer frischen VM, die deine Caches lesen, aber nicht ändern kann; deine eigene Maschine führt nur den Code deines Teams aus.

Ja. Die Tarife kosten $39, $79 oder $149 im Monat, in US-Dollar abgerechnet, monatlich oder jährlich im Voraus zum Preis von 10 Monaten, ohne nutzungsabhängige Kosten. Ein Tarif begrenzt, wie viele Jobs gleichzeitig laufen und wie groß jeder ist, nicht die Minuten: Ein Job, der nicht hineinpasst, wartet, bis ein laufender endet, und das Warten erhöht deine Rechnung nicht. Die Seite deiner Organisation in Skipbox zeigt, wie viele Jobs warten und wie lange der älteste schon wartet. Ein Job kann bis zu 6 Stunden laufen.

Parallele Jobs werden in Jobs mit 4 vCPU gezählt. Ein Tarif führt Jobs bis zu seiner vCPU-Summe gleichzeitig aus (S 4, M 8, L 16 vCPU), also zählt ein Job mit 8 vCPU als 2 und einer mit 16 vCPU als 4. Der größte einzelne Job, den ein Tarif ausführen kann, entspricht seiner vCPU-Zahl: 4 bei S, 8 bei M, 16 bei L. Füge Tarife hinzu, um mehr Jobs gleichzeitig auszuführen.

Jeder Skipbox-S-Job bekommt 4 vCPU und 16 GB; ubuntu-latest von GitHub hat in einem privaten Repository 2 Kerne und 8 GB. Deine eigene Maschine behält außerdem Docker-Layer und Paket-Caches deines letzten Jobs, sodass ein Build, der sie nutzt, sie nicht erneut herunterlädt; ein von GitHub gehosteter Job startet jedes Mal auf einer neuen VM. docker build und docker compose build verwenden die Layer wieder. Der Standard-Builder von docker/setup-buildx-action startet in jedem Job leer, also setze dort driver: docker, um den eigenen Cache der Maschine zu nutzen. Nachdem dein erster Job auf Skipbox gelaufen ist, zeigt das Dashboard seine Zeit neben seinem Median auf GitHub über die letzten 30 Tage, sofern GitHub ihn in dieser Zeit ausgeführt hat.

16 GB im Tarif S auf deiner eigenen Maschine: 2× so viel wie die 8 GB von ubuntu-latest in einem privaten Repository und genauso viel wie der „Larger Runner“ von GitHub mit 4 Kernen. Der Tarif S hatte früher 8 GB, und das reichte für openai/codex (rust-v0.159.3) nicht: cargo clippy --workspace --tests lief nur durch, weil etwa 14 GB in komprimierten Swap ausgelagert wurden. Mit den heutigen 16 GB lagert derselbe Build nur etwa 20 MB aus. Für einen Job, der mehr braucht, hat Tarif L 32 GB.

Nur auf das, was es braucht, um Runner zu registrieren und Jobs zu prüfen. In einer Organisation fragt die App Skipbox CI nach drei Berechtigungen: Self-hosted runners (Schreiben), um für jeden Job einen Runner bei GitHub zu registrieren und ihn zu entfernen, wenn der Job endet; Actions (Lesen und Schreiben), um zu sehen, welche Jobs warten, ihren Status zu prüfen, für dein Angebot zu lesen, wie lange deine Jobs in den letzten 30 Tagen liefen, und einen Job erneut auszuführen, dessen Skipbox-Maschine mitten im Job angehalten hat; und Metadata (Lesen). Die App Skipbox CI bearbeitet oder pusht deine Workflows nie und kann deinen Code nicht lesen: Jeder Job checkt deinen Code selbst aus, auf der VM, auf der er läuft. In einem persönlichen Konto registriert GitHub einen Runner für ein Repository nur mit der Berechtigung Administration, die auch die Einstellungen, Mitarbeitenden und Deploy-Keys des Repositorys umfasst. Skipbox (personal) fragt danach und nutzt sie nur, um Runner zu registrieren und zu entfernen. Eine Funktion ist die Ausnahme, und nur, wenn du sie installierst: Die Schaltfläche „Pull Request öffnen“ im Dashboard nutzt eine eigene App, Skipbox Migrate, die du nur in den Repositorys installierst, die du auswählst. Dort fragt sie nach Schreibzugriff auf Contents, Workflows und Pull requests, pusht einen Branch (skipbox/run-ci-on-skipbox), der nur runs-on-Zeilen ändert, und öffnet daraus einen Pull Request. Sie mergt nie und rührt deinen Standardbranch nicht an. Bei der Anmeldung liest Skipbox außerdem deine E-Mail-Adresse für Hinweise zur Testphase und zur Abrechnung. Wie bei jedem Runner enthält die VM eines Jobs die Secrets deines Workflows und das GitHub-Token für diesen Job, sodass Code, den der Job ausführt, sie lesen kann.

Auf der eigenen Maschine deiner Organisation: eine VM in der Größe deines Tarifs (auch während der Testphase), eine weitere mit jedem zusätzlichen Tarif. Keine andere Organisation nutzt sie. Sie läuft zwischen deinen Jobs weiter, sodass Docker-Images, Caches, dein Checkout und seine Build-Ausgabe (Cargos target/ und bei turbo 2 der Cache von Turborepo) für deine nächsten Jobs erhalten bleiben. Sie läuft auf Servern, die Fluxenic, das Unternehmen hinter Skipbox, bei Cloud-Anbietern mietet oder selbst betreibt. Die Datenschutzerklärung nennt jeden Anbieter und jedes Land. Nach jedem Job werden die Zugangsdaten des Runners, die Git-Zugangsdaten in deinem Checkout und gängige Dateien mit Zugangsdaten gelöscht. Jobs über deine eigenen Maschinen hinaus, Code von Personen ohne Schreibzugriff (etwa Pull Requests aus Forks) und jeder Job mit „Jeder Job sauber“ laufen auf einer neuen VM, die samt Festplatte gelöscht wird, wenn der Job endet. Ein Job, der nach 6 Stunden noch läuft, wird gestoppt. Aus dem Internet kann sich nichts hineinverbinden. Ausgehende E-Mails (TCP-Port 25) sind blockiert. Der Rest des Internets ist offen, wie bei von GitHub gehosteten Runnern. Datenverkehr wird nicht berechnet.

Ja. Drück jederzeit unter „Tarife und Abrechnung“ auf „Maschine zurücksetzen“. Schalte dort „Jeder Job sauber“ ein, und jeder Job läuft auf einer neuen VM.

Du kannst jederzeit kündigen; dein Tarif läuft bis zum Ende des bezahlten Monats oder Jahres. Sind deine Jobs auf Skipbox nicht schneller als auf GitHub, bekommst du alles zurück, was du bezahlt hast, bei Monats- und Jahrestarifen gleichermaßen: Beantrage es innerhalb von 30 Tagen nach deiner ersten Zahlung auf der Seite „Tarife und Abrechnung“ deines Kontos. Skipbox nimmt die Medianzeit jedes Jobs auf Skipbox und auf GitHub (in den 30 Tagen vor der Installation von Skipbox), gewichtet jeden Job danach, wie oft er auf GitHub lief, und vergleicht die beiden Summen; ein Job zählt, sobald er auf beiden mindestens 3-mal gelaufen ist, und ohne vergleichbaren Job gibt es nichts zu erstatten. Startet der erste Job nach dem Abschluss nicht innerhalb von 10 Minuten (Wartezeit hinter deinen eigenen Jobs nicht mitgerechnet), erstatten wir dir automatisch die volle Zahlung und beenden den Tarif. Ansonsten wird ein bezahlter Monat oder ein bezahltes Jahr nicht erstattet, außer in den Fällen, die die Nutzungsbedingungen nennen.

Es wird nichts berechnet: Die Testphase braucht keine Karte. Sie beginnt mit deinem ersten Job auf Skipbox, nicht bei der Anmeldung oder der Installation der App, und führt 7 Tage oder 3.000 Minuten lang einen 4 vCPU · 16 GB-Job gleichzeitig aus, je nachdem, was zuerst eintritt. Es gibt 1 Testphase pro Konto und 1 pro Person. Wenn sie endet, warten neue Jobs auf GitHub, bis du einen Tarif wählst.

Ändere runs-on auf skipbox, um zu wechseln, und zurück auf ubuntu-latest, um zurückzugehen. Melde dich mit GitHub an, installiere die App Skipbox CI in deiner Organisation oder Skipbox (personal) in deinem persönlichen Konto, ändere die runs-on-Zeile des Jobs auf skipbox und committe; für eine größere VM in Tarifen, die eine enthalten, nutze skipbox-8x16 oder skipbox-16x32. Zum Zurückwechseln änderst du runs-on: skipbox wieder auf runs-on: ubuntu-latest. Sonst hat sich in deinem Repository nichts geändert.