Sandbox voor CI: geïsoleerde testruns voor minder dan een cent per stuk

Self-hosted CI-runners hebben één lastige eigenschap: ze onthouden alles. Caches, tokens, een deploy-key die iemand vorig voorjaar „tijdelijk” heeft toegevoegd. Voor uw eigen branches is dat prima. Het wordt een probleem zodra er een pull request binnenkomt van iemand van wie u nog nooit hebt gehoord — of van uw eigen AI-agent, die een patch schreef die nog niemand heeft gelezen.

Het schone antwoord is één machine per run. Clonen, installeren, testen, machine weggooien.

Hoe een run eruitziet

Een sandbox is een Firecracker-microVM die in ongeveer een seconde start met Python 3.12, Node.js 22, git en curl. Uitgaand internet werkt, dus git clone en pip install -r requirements.txt gedragen zich zoals gewoonlijk. Er zijn geen inkomende poorten — niets kan de testomgeving bereiken terwijl die draait.

Vanuit een CI-job is het geheel een kort script. Hier met de Python-SDK, aan te roepen vanuit elke CI-job:

import os, sys
from eqvps import Sandbox

repo, ref = os.environ["REPO_URL"], os.environ["PR_SHA"]

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone {repo} /root/app && cd /root/app && git checkout {ref}", timeout=55)
    sb.exec("cd /root/app && pip install -r requirements.txt", timeout=55)
    task = sb.exec("cd /root/app && python3 -m pytest -q", background=True)
    result = task.wait(on_output=lambda out, err: print(out, end=""))
sys.exit(result.exit_code or 0)

Het token staat in uw CI-secrets als EQVPS_API_KEY. Verder gaat er niets uit uw CI de sandbox in — geen deploy-keys, geen cloudgegevens. Wanneer het with-blok eindigt, wordt de sandbox verwijderd, ook als de job halverwege is gecrasht.

De testrun zelf is een achtergrondtaak, omdat één synchrone opdracht na 55 seconden stopt. Een achtergrondtaak streamt uitvoer terwijl hij werkt en kan doorgaan tot de TTL van de sandbox — hier 30 minuten, zodat een vastgelopen test de rekening niet opdrijft.

De limieten waar u echt tegenaan loopt

Daar eerlijk over zijn bespaart u een middag.

Gelijktijdigheid. Een account kan 20 sandboxes hebben, maar slechts 2 opdrachten worden tegelijk uitgevoerd. Voor CI zijn dat twee jobs die echt parallel draaien. Tien PR's die tegelijk binnenkomen, sluiten aan in de rij. Als uw pipeline tests over 16 workers verdeelt, is dit het verkeerde gereedschap voor de hoofdpipeline — houd die op uw eigen runners op een VPS en gebruik sandboxes voor de onbetrouwbare baan.

Geen containers binnenin. Docker zit niet in de sandbox. Unit- en integratietests die een Postgres-container nodig hebben, werken niet zomaar; tests tegen SQLite of een in-memory fake wel.

Bestanden. Uploads en downloads via de API gaan tot 5 MB per bestand. Haal de code met git binnen in de sandbox in plaats van een archief te uploaden.

Wat het kost

U betaalt de vCPU en het RAM van het tarief per seconde, minimaal 60 seconden, vanuit een prepaid tegoed — zonder abonnement.

Bij deze prijzen is de interessante vraag niet de prijs, maar of uw tests binnen de ingestelde tijd klaar zijn. Geef de TTL wat speling boven uw traagste groene run.

Een verstandige verdeling

Ons advies: houd vertrouwde branches op uw snelle runner met cache. Stuur alles wat u niet zelf schreef — forks, externe bijdragers, door agents gegenereerde patches — eerst door een sandbox. Is de sandboxrun groen en heeft een mens de diff bekeken, promoveer hem dan naar de vertrouwde pipeline.

Zo hebt u één baan waar snelheid en cache tellen en één waar een schone machine telt, zonder één gereedschap te dwingen beide te zijn.

Begin met het overzicht van sandboxes en de verbindingshandleiding — nieuwe accounts krijgen $1 aan sandboxtijd, genoeg voor een paar honderd korte testruns. Elke hierboven gebruikte methode staat in de SDK-referentie, en de exacte factureringsregels in limieten en facturering van sandboxes.

Gerelateerd: sandbox voor code review en PR-controles en sandbox voor AI-agents.