Sandbox pour la CI : des tests isolés pour moins d'un centime par exécution

Les runners CI auto-hébergés ont une propriété gênante : ils se souviennent de tout. Des caches, des tokens, une clé de déploiement que quelqu'un a ajoutée « temporairement » au printemps dernier. Pour vos propres branches, ça va. Le problème commence quand une pull request arrive de quelqu'un dont vous n'avez jamais entendu parler — ou de votre propre agent IA, qui a écrit un patch que personne n'a encore lu.

La réponse propre : une machine par exécution. Cloner, installer, tester, jeter la machine.

À quoi ressemble une exécution

Une sandbox est une microVM Firecracker qui démarre en une seconde environ avec Python 3.12, Node.js 22, git et curl. L'accès Internet sortant fonctionne, donc git clone et pip install -r requirements.txt se comportent normalement. Il n'y a pas de ports entrants — rien ne peut joindre l'environnement de test pendant qu'il tourne.

Depuis un job CI, le tout tient dans un court script. Le voici avec le SDK Python, appelable depuis n'importe quel job CI :

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)

Le token se trouve dans vos secrets CI sous le nom EQVPS_API_KEY. Rien d'autre de votre CI — ni clés de déploiement, ni identifiants cloud — n'entre dans la sandbox. Quand le bloc with se termine, la sandbox est supprimée, même si le job a planté en cours de route.

L'exécution des tests elle-même est une tâche de fond, car une commande synchrone s'arrête à 55 secondes. Une tâche de fond diffuse sa sortie au fil de l'eau et peut continuer jusqu'au TTL de la sandbox — fixé ici à 30 minutes pour qu'un test bloqué ne fasse pas grimper la facture.

Les limites que vous rencontrerez vraiment

En parler franchement vous fera gagner un après-midi.

Parallélisme. Un compte peut détenir 20 sandboxes, mais seulement 2 commandes s'exécutent en même temps. Pour la CI, cela fait deux jobs vraiment parallèles. Dix PR arrivées d'un coup feront la queue. Si votre pipeline répartit les tests sur 16 workers, ce n'est pas le bon outil pour le pipeline principal — gardez-le sur vos propres runners sur un VPS et utilisez les sandboxes pour la voie non fiable.

Pas de conteneurs à l'intérieur. Docker n'est pas fourni dans la sandbox. Les tests unitaires et d'intégration qui ont besoin d'un conteneur Postgres ne fonctionneront pas tels quels ; ceux qui tournent contre SQLite ou un faux en mémoire, si.

Fichiers. Les envois et téléchargements via l'API vont jusqu'à 5 MB par fichier. Récupérez le code avec git dans la sandbox plutôt que d'envoyer une archive.

Ce que ça coûte

Vous payez les vCPU et la RAM du tarif à la seconde, 60 secondes minimum, depuis un solde prépayé — sans abonnement.

À ces prix, la question intéressante n'est pas le coût, mais de savoir si vos tests finissent dans le temps imparti. Laissez au TTL une marge au-dessus de votre exécution verte la plus lente.

Un partage raisonnable

Notre recommandation : gardez les branches de confiance sur votre runner rapide avec cache. Faites d'abord passer par une sandbox tout ce que vous n'avez pas écrit — forks, contributeurs externes, patchs générés par des agents. Si l'exécution en sandbox est verte et qu'un humain a regardé le diff, promouvez-la vers le pipeline de confiance.

Vous obtenez ainsi une voie où vitesse et cache comptent, et une autre où une machine propre compte, sans forcer un seul outil à être les deux.

Commencez par la présentation des sandboxes et le guide de connexion — les nouveaux comptes reçoivent $1 de temps de sandbox, de quoi couvrir quelques centaines de courtes exécutions. Toutes les méthodes utilisées plus haut figurent dans la référence du SDK, et les règles de facturation exactes dans limites et facturation des sandboxes.

À lire aussi : sandbox pour la revue de code et les vérifications de PR et sandbox pour agents IA.