Esteira

Uma plataforma para dois tipos de trabalho

Um job de CI e uma sessão de agente querem a mesma coisa: uma máquina limpa, um limite rígido e nada deixado para trás.

Pipelines

Aponte um job para a Esteira e ele roda em uma máquina provisionada para aquele job e destruída quando ele termina. Nada mais se move. Logs, artefatos, caches, segredos e agendamento continuam no seu CI, então não há um segundo painel para aprender nem nada para migrar de volta se você sair.

GitHub Actions hoje, GitLab CI em breve. Pipelines Linux existentes rodam mudando só o label, incluindo service containers e builds Docker. Veja o que já foi verificado.

Agentes

Dê ao agente um sandbox com CPU e memória fixas e um tempo de vida. Ele executa comandos como arrays de argumentos, mantém o workspace entre eles e desaparece quando o tempo acaba ou quando você mandar. Uma requisição repetida devolve o mesmo sandbox em vez de criar um segundo.

Uma API REST com chaves por organização. Permissões por chave: read, create, execute, delete.

O que muda, e o que fica onde está

Trocar o runner não é trocar de CI. Seus workflows, seu histórico e seus segredos não saem do lugar.

Critério	Hospedado pelo GitHub ou GitLab	Self-hosted	Esteira
O que muda no workflow	Nada	Instalar e manter runners	Um label
Quem mantém as máquinas	GitHub ou GitLab	Você	Esteira
Onde ficam logs, artefatos e segredos	GitHub ou GitLab	GitHub ou GitLab	GitHub ou GitLab
Onde as máquinas rodam	Fora do Brasil	Onde você colocar	Brasil
Moeda da fatura	Dólar	A da sua nuvem	Real

Três chamadas do zero a um comando rodando, e de volta

Todo caminho carrega a sua organização. A criação é idempotente, então uma resposta perdida nunca custa uma máquina esquecida.

1Crie um sandbox

Envie os limites de CPU e memória e um UUID como Idempotency-Key. Repita com a mesma chave e a mesma especificação e você recebe este mesmo sandbox de volta. Mude a especificação com a mesma chave e a requisição falha com 409.

POST /v1/organizations/{org}/sandboxes
X-API-Key: ••••••••
Idempotency-Key: 4a6d3b0e-…

{"cpu": 1, "memory_mb": 256, "ttl_seconds": 300}

201 Created
{
  "id": "0c2f9a51-…",
  "image": "python:3.13-slim",
  "state": "running",
  "cpu": 1,
  "memory_mb": 256,
  "created_at": "2026-09-27T18:40:02Z",
  "expires_at": "2026-09-27T18:45:02Z"
}

2Execute um comando

Comandos são arrays de argumentos, nunca uma string de shell interpolada em um host. Você recebe stdout, stderr e o código de saída. Um comando que estoura o timeout ou o limite de saída destrói o sandbox e todos os processos que ele iniciou.

POST /v1/organizations/{org}/sandboxes/{id}/commands

{"command": ["python", "-c", "print(6 * 7)"], "timeout_seconds": 10}

200 OK
{"exit_code": 0, "stdout": "42\n", "stderr": ""}

3Destrua

A exclusão é durável. Repeti-la funciona. Reutilizar a Idempotency-Keyoriginal depois retorna 410 em vez de ressuscitar o ambiente em silêncio.

DELETE /v1/organizations/{org}/sandboxes/{id}

204 No Content

O que um sandbox pode e não pode fazer

Os limites fazem parte do contrato, não são uma configuração que a carga de trabalho pode afrouxar.

Rede: Nenhuma. Sem rede externa, sem portas publicadas, sem montagens do host, sem acesso ao engine de containers.
Privilégios: Roda como usuário não root, com todas as capabilities removidas e sem como obter novas.
Sistema de arquivos: Raiz somente leitura com um workspace gravável temporário. O workspace vive exatamente o tempo do sandbox.
Limites: De 0,1 a 4 vCPU, de 64 MB a 4 GB de memória, vida útil de até uma hora. Comandos têm timeout de até 300 segundos e a saída é limitada a 1 MiB. Estourar qualquer um dos dois destrói o sandbox.
Imagem: Escolhida pelo operador e baixada com antecedência. Nenhuma requisição faz a plataforma baixar algo novo.
Chaves: Pertencem à organização, não a quem as criou, e sobrevivem à saída dessa pessoa. Com escopo nas ações que você escolher, válidas por 90 dias salvo indicação em contrário, limitadas a 120 requisições por minuto e revogáveis na hora.

Perguntas frequentes

Preciso mudar meu workflow?: Só o label do runner. O arquivo de workflow, os steps, as actions e os segredos continuam iguais. Se um dia sair da Esteira, é a mesma linha de volta.
Onde ficam meus logs, artefatos e segredos?: No seu CI, como hoje. A gente fornece a máquina que executa o job e nada mais. Não existe um segundo painel para acompanhar builds.
Onde as máquinas rodam?: Em data centers no Brasil. Cada job ou sandbox vai receber uma máquina própria, destruída quando o trabalho termina.
Como é a cobrança?: Por segundo de máquina em uso, em reais, com nota fiscal brasileira. Sem câmbio e sem IOF na fatura. A tabela de preços será publicada com a abertura do acesso.
O que já funciona hoje?: A API de sandbox descrita acima: criação idempotente, execução de comandos, exclusão durável e chaves com escopo por organização. Ela roda em um runtime de desenvolvimento baseado em containers. Runners para GitHub Actions, com uma máquina virtual por job, já passaram no nosso teste de integração e estão em validação com os primeiros times. GitLab CI está planejado. A lista completa está na página de compatibilidade.

Máquinas no Brasil. Nota fiscal em reais.

Sem câmbio na fatura, sem IOF por cima e cobrança por segundo: um job de dois minutos custa dois minutos. Estamos abrindo acesso para um número pequeno de times. Conte sobre seus pipelines ou seus agentes e a gente responde.

Pedir acesso antecipado

Runners para o seu CI. Sandboxes para os seus agentes. Máquinas no Brasil.