Sandbox para CI: execuções de testes isoladas por menos de um centavo cada

Runners de CI self-hosted têm uma propriedade incômoda: eles lembram de tudo. Caches, tokens, uma chave de deploy que alguém adicionou "temporariamente" na primavera passada. Para os seus próprios branches, tudo bem. O problema começa quando chega um pull request de alguém de quem você nunca ouviu falar — ou do seu próprio agente de IA, que escreveu um patch que ninguém leu ainda.

A resposta limpa é uma máquina por execução. Clonar, instalar, testar, jogar a máquina fora.

Como é uma execução

Uma sandbox é uma microVM Firecracker que inicia em cerca de um segundo com Python 3.12, Node.js 22, git e curl. A internet de saída funciona, então git clone e pip install -r requirements.txt se comportam como sempre. Não há portas de entrada — nada consegue chamar o ambiente de testes enquanto ele roda.

A partir de um job de CI, tudo cabe num script curto. Aqui está com o SDK de Python, chamado de qualquer job de 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)

O token fica nos secrets do seu CI como EQVPS_API_KEY. Nada mais do seu CI — nem chaves de deploy, nem credenciais de nuvem — entra na sandbox. Quando o bloco with termina, a sandbox é apagada, mesmo que o job tenha falhado no meio.

A execução dos testes em si é uma tarefa em segundo plano, porque um único comando síncrono para aos 55 segundos. Uma tarefa em segundo plano transmite a saída enquanto trabalha e pode continuar até o TTL da sandbox — aqui definido em 30 minutos para que um teste travado não infle a conta.

Os limites que você vai encontrar de verdade

Falar deles com franqueza economiza uma tarde.

Concorrência. Uma conta pode ter 20 sandboxes, mas só 2 comandos executam ao mesmo tempo. Para CI, são dois jobs realmente em paralelo. Dez PRs chegando juntos vão para a fila. Se o seu pipeline divide os testes entre 16 workers, esta não é a ferramenta para o pipeline principal — mantenha-o nos seus próprios runners num VPS e use sandboxes para a faixa não confiável.

Sem contêineres dentro. O Docker não vem na sandbox. Testes unitários e de integração que precisam de um contêiner Postgres não vão funcionar como estão; testes contra SQLite ou um fake em memória, sim.

Arquivos. Uploads e downloads pela API vão até 5 MB por arquivo. Traga o código com git dentro da sandbox em vez de enviar um arquivo compactado.

Quanto custa

Você paga os vCPU e a RAM do plano por segundo, mínimo de 60 segundos, a partir de um saldo pré-pago — sem assinatura.

Com esses preços, a pergunta interessante não é o custo, e sim se os seus testes terminam dentro do tempo definido. Dê ao TTL alguma folga acima da sua execução verde mais lenta.

Uma divisão sensata

Nossa recomendação: mantenha os branches confiáveis no seu runner rápido com cache. Passe primeiro por uma sandbox tudo o que você não escreveu — forks, colaboradores externos, patches gerados por agentes. Se a execução na sandbox ficar verde e uma pessoa tiver olhado o diff, promova-o para o pipeline confiável.

Assim você tem uma faixa onde velocidade e cache importam e outra onde uma máquina limpa importa, sem forçar uma única ferramenta a ser as duas coisas.

Comece pela visão geral das sandboxes e pelo guia de conexão — contas novas recebem $1 de tempo de sandbox, o que cobre algumas centenas de execuções curtas. Todos os métodos usados acima estão na referência do SDK, e as regras exatas de cobrança em limites e cobrança das sandboxes.

Relacionado: sandbox para revisão de código e verificação de PRs e sandbox para agentes de IA.