Draaien mijn workflows zonder aanpassingen?
Ja, de meeste wel. Skipbox draait de workflows van openbare en privé-repository's op GitHub-organisaties en persoonlijke accounts. De VM is Ubuntu 24.04 op x64 met Docker, git, build-essential, Node 22 en Python 3.12, en de job draait als een gebruiker met sudo zonder wachtwoord, net als op de runners van GitHub. De ubuntu-latest-image van GitHub heeft meer vooraf geïnstalleerd, dus voeg actions/setup-java, actions/setup-go en dergelijke toe voor andere tools.
Waarom is het zo goedkoop?
Nu AI meer van de code schrijft, draait CI elke maand vaker, en facturering per minuut groeit met elke run mee. Daarom koos Skipbox bewust een ander model: je huurt per maand een VM die alleen voor je account is. GitHub rekent geen minuten voor self-hosted runners, dus hoeveel jobs je ook draait, de prijs blijft vast $39 per maand voor S. Fluxenic, het bedrijf achter Skipbox, draait servers van goedkope cloudproviders en eigen servers, en levert ze als VM's van een bruikbaar formaat. Skipbox doet het saaie werk voor je: het registreert de runners, ruimt na elke job op en controleert de gezondheid van de machine. Het bouwt ook een kapotte machine opnieuw op en houdt de image actueel. Bij volledig gebruik is de prijs 1/12 van die van GitHub en 1/8 van die van Blacksmith.
Waarom is het zo snel?
Omdat de machine alleen van je account is en tussen jobs blijft draaien. Docker-layers en packagecaches van je vorige job staan nog op de schijf, dus een build die ze gebruikt hoeft ze niet op te halen of opnieuw te bouwen. Een job op een door GitHub gehoste runner start elke keer op een nieuwe VM met een lege schijf. Zelfs S bewaart zijn caches op een eigen schijf van 80 GB. Dat is meer dan 7x de cache die GitHub standaard per repository geeft, en niets daarin verloopt na 7 dagen zonder gebruik. S heeft ook 4 vCPU, meer dan de 2 cores van ubuntu-latest op een privé-repository.
Is het niet goedkoper om zelf een VPS als runner te huren?
Huur een VPS van hetzelfde formaat bij een grote host en je krijgt nog steeds geen self-hosted runner die goedkoper, sneller en minder werk is dan Skipbox. Skipbox registreert voor elke job een nieuwe runner en verwijdert hem daarna. Na elke job wist het de credentials van de runner en bewaart het je checkout en builduitvoer voor de volgende. Het controleert de gezondheid van de machine, bouwt hem opnieuw op als de controle faalt en houdt de image actueel. Code van mensen zonder schrijfrechten (zoals pull requests vanuit forks) draait op een wegwerp-VM. Dat alles krijg je voor $39 per maand op S, door één runs-on-regel te wijzigen, zonder iets te onderhouden.
Draait Skipbox openbare repository's?
Ja, openbare en privé-repository's allebei. Code van mensen zonder schrijfrechten (zoals pull requests vanuit forks) draait op een nieuwe VM die je caches kan lezen maar niet kan wijzigen; je eigen machine draait alleen de code van je team.
Zijn de minuten echt onbeperkt?
Ja. Abonnementen kosten $39, $79 of $149 per maand, gefactureerd in Amerikaanse dollars, maandelijks of een jaar vooruit voor de prijs van 10 maanden, zonder gebruikskosten. Een abonnement beperkt hoeveel jobs tegelijk draaien en hoe groot elke job is, niet de minuten: een job die niet past, wacht tot een lopende job klaar is, en wachten voegt niets toe aan je rekening. De pagina van je organisatie in Skipbox toont hoeveel jobs er wachten en hoe lang de oudste al wacht. Een job kan maximaal 6 uur draaien.
Hoe tellen grotere jobs mee voor gelijktijdige jobs?
Gelijktijdige jobs worden geteld in jobs van 4 vCPU. Een abonnement draait tegelijk jobs tot zijn totaal aan vCPU (S 4, M 8, L 16 vCPU), dus een job van 8 vCPU telt als 2 en een van 16 vCPU als 4. De grootste losse job die een abonnement kan draaien, is zijn aantal vCPU: 4 op S, 8 op M, 16 op L. Voeg abonnementen toe om meer jobs tegelijk te draaien.
Hoe verhoudt Skipbox zich tot de runners van GitHub?
Elke job op Skipbox S krijgt 4 vCPU en 16 GB; ubuntu-latest van GitHub op een privé-repository heeft 2 cores en 8 GB. Je eigen machine bewaart ook Docker-layers en packagecaches van je vorige job, dus een build die ze gebruikt hoeft ze niet opnieuw op te halen; een job op een door GitHub gehoste runner start elke keer op een nieuwe VM. docker build en docker compose build hergebruiken de layers. De standaardbuilder van docker/setup-buildx-action start in elke job leeg, dus zet daarop driver: docker om de eigen cache van de machine te gebruiken. Nadat je eerste job op Skipbox heeft gedraaid, toont het dashboard de tijd ervan naast de mediaan op GitHub over de afgelopen 30 dagen, als GitHub hem toen draaide.
Mijn build heeft te weinig geheugen op de runner van GitHub. Hoeveel geheugen heeft Skipbox?
16 GB op abonnement S, op je eigen machine: 2× de 8 GB van ubuntu-latest op een privé-repository, en evenveel als de larger runner van GitHub met 4 cores. Abonnement S had vroeger 8 GB, en dat was niet genoeg voor openai/codex (rust-v0.159.3): cargo clippy --workspace --tests slaagde alleen doordat ongeveer 14 GB naar gecomprimeerde swap werd verplaatst. Met de huidige 16 GB gaat bij dezelfde build ongeveer 20 MB naar swap. Voor een job die meer nodig heeft, heeft abonnement L 32 GB.
Waar heeft Skipbox toegang toe?
Alleen tot wat het nodig heeft om runners te registreren en jobs te controleren. Op een organisatie vraagt de app Skipbox CI om drie rechten: Self-hosted runners (schrijven), om voor elke job een runner bij GitHub te registreren en die te verwijderen als de job klaar is; Actions (lezen en schrijven), om te zien welke jobs wachten, hun status te controleren, voor je offerte te lezen hoe lang je jobs de afgelopen 30 dagen hebben gedraaid, en een job opnieuw uit te voeren waarvan de Skipbox-machine halverwege stopte; en Metadata (lezen). De app Skipbox CI bewerkt of pusht je workflows nooit en kan je code niet lezen: elke job checkt je code zelf uit, op de VM waarop hij draait. Op een persoonlijk account registreert GitHub alleen een runner voor een repository met het recht Administration, dat ook de instellingen, collaborators en deploy keys van de repository omvat. Skipbox (personal) vraagt erom en gebruikt het alleen om runners te registreren en te verwijderen. Eén functie is de uitzondering, en alleen als je hem installeert: de knop ‘Pull request openen’ in het dashboard gebruikt een aparte app, Skipbox Migrate, die je alleen installeert op de repository's die je kiest. Daar vraagt hij om schrijfrechten op Contents, Workflows en Pull requests, pusht hij één branch (skipbox/run-ci-on-skipbox) die alleen runs-on-regels wijzigt en opent hij daar een pull request vanuit. Hij merget nooit en raakt je standaardbranch nooit aan. Als je inlogt, leest Skipbox ook je e-mailadres, voor meldingen over de proefperiode en facturering. Zoals op elke runner bevat de VM van een job de secrets van je workflow en het token van GitHub voor die job, dus code die de job draait kan ze lezen.
Waar draaien de jobs?
Op de eigen machine van je organisatie: een VM van het formaat van je abonnement (ook tijdens de proefperiode), plus één per extra abonnement. Geen andere organisatie gebruikt hem. Hij blijft tussen je jobs draaien, dus Docker-images, caches, je checkout en de builduitvoer ervan (target/ van Cargo, en met turbo 2 de cache van Turborepo) blijven bewaard voor je volgende jobs. Hij draait op servers die Fluxenic, het bedrijf achter Skipbox, huurt van cloudproviders of zelf beheert. Het privacybeleid noemt elke provider en elk land. Na elke job worden de credentials van de runner, de git-credentials in je checkout en gangbare credentialbestanden gewist. Jobs die niet meer op je eigen machines passen, code van mensen zonder schrijfrechten (zoals pull requests vanuit forks) en elke job met Schone VM per job draaien op een nieuwe VM, die met zijn schijf wordt verwijderd als de job klaar is. Een job die na 6 uur nog draait, wordt gestopt. Vanaf internet kan niets een verbinding maken. Uitgaande mail (TCP-poort 25) is geblokkeerd. De rest van internet is open, net als op door GitHub gehoste runners. Dataverkeer wordt niet in rekening gebracht.
Kan ik mijn machine opnieuw laten beginnen, of elke job op een nieuwe VM draaien?
Ja. Klik op Machine resetten in Abonnementen en facturering, op elk moment. Zet daar Schone VM per job aan, dan draait elke job op een nieuwe VM.
Kunnen we opzeggen of ons geld terugkrijgen?
Je kunt op elk moment opzeggen; je abonnement loopt door tot het eind van de maand of het jaar dat je hebt betaald. Zijn je jobs op Skipbox niet sneller dan ze op GitHub waren, dan krijg je alles terug wat je hebt betaald, bij maand- en jaarabonnementen allebei: vraag het aan op de pagina Abonnementen en facturering van je account, binnen 30 dagen na je eerste betaling. Skipbox neemt de mediane tijd van elke job op Skipbox en op GitHub (de 30 dagen voordat je Skipbox installeerde), weegt elke job naar hoe vaak hij op GitHub draaide en vergelijkt de twee totalen; een job telt mee zodra hij op elk minstens 3 keer heeft gedraaid, en zonder job om te vergelijken valt er niets terug te betalen. Start de eerste job die je na het afsluiten van een abonnement draait niet binnen 10 minuten, de tijd niet meegerekend dat hij achter je eigen jobs wacht, dan betalen we je betaling automatisch volledig terug en beëindigen we het abonnement. Verder wordt een betaalde maand of een betaald jaar niet terugbetaald, behalve in de gevallen die de Servicevoorwaarden noemen.
Wat gebeurt er als de proefperiode afloopt? Betaal ik dan?
Er wordt niets in rekening gebracht: voor de proefperiode is geen kaart nodig. Hij start bij je eerste job op Skipbox, niet als je inlogt of de app installeert, en draait één 4 vCPU · 16 GB-job tegelijk gedurende 7 dagen of 3.000 minuten, wat het eerst komt. Er is 1 proefperiode per account en 1 per persoon. Als hij afloopt, wachten nieuwe jobs op GitHub tot je een abonnement kiest.
Hoe draai ik een job op Skipbox, en hoe ga ik terug?
Wijzig runs-on in skipbox om over te stappen, en terug in ubuntu-latest om terug te gaan. Log in met GitHub, installeer de app Skipbox CI op je organisatie of Skipbox (personal) op je persoonlijke account, wijzig de runs-on-regel van de job in skipbox en commit; voor een grotere VM op abonnementen die er een bevatten, gebruik je skipbox-8x16 of skipbox-16x32. Om terug te gaan wijzig je runs-on: skipbox weer in runs-on: ubuntu-latest. Verder is er niets in je repository veranderd.