Meus fluxos de trabalho vão rodar sem mudanças?
Sim, a maioria. O Skipbox roda os fluxos de trabalho de repositórios públicos e privados em organizações e contas pessoais do GitHub. A VM é Ubuntu 24.04 em x64 com Docker, git, build-essential, Node 22 e Python 3.12, e o trabalho roda como um usuário com sudo sem senha, como nos executores do GitHub. A imagem ubuntu-latest do GitHub tem mais coisas pré-instaladas, então adicione actions/setup-java, actions/setup-go e similares para outras ferramentas.
Por que é tão barato?
Com a IA escrevendo mais código, o CI roda mais a cada mês, e a cobrança por minuto cresce a cada execução. Por isso o Skipbox escolheu outro modelo de propósito: você aluga uma VM só da sua conta, por mês. O GitHub não cobra os minutos de executores auto-hospedados, então, não importa quantos trabalhos você rode, o preço fica fixo em $39 por mês no S. A Fluxenic, empresa por trás do Skipbox, roda servidores de provedores de nuvem de baixo custo e servidores próprios, e os oferece como VMs de um tamanho útil. O Skipbox faz a parte chata por você: registra os executores, limpa tudo depois de cada trabalho e verifica a integridade da máquina. Também recria uma máquina quebrada e mantém a imagem atualizada. Com uso total, o preço é 1/12 do preço do GitHub e 1/8 do preço do Blacksmith.
Por que é tão rápido?
Porque a máquina é só da sua conta e continua ligada entre os trabalhos. As camadas Docker e o cache de pacotes do seu último trabalho continuam no disco, então um build que os usa não precisa baixá-los nem recriá-los. Um trabalho hospedado pelo GitHub começa sempre em uma VM nova, com o disco vazio. Até o S mantém o cache no próprio disco de 80 GB. Isso é mais de 7x o cache que o GitHub dá por padrão a um repositório, e nada nele expira depois de 7 dias sem uso. O S também tem 4 vCPU, mais que os 2 núcleos do ubuntu-latest em um repositório privado.
Alugar a minha própria VPS como executor não sairia mais barato?
Alugue uma VPS do mesmo tamanho em um grande provedor e você ainda não terá um executor auto-hospedado mais barato, mais rápido e com menos trabalho que o Skipbox. O Skipbox registra um executor novo para cada trabalho e o remove depois. Ao fim de cada trabalho, apaga as credenciais do executor e guarda o seu checkout e a saída de build para o próximo. Verifica a integridade da máquina, recria a máquina quando a verificação falha e mantém a imagem atualizada. O código de pessoas sem acesso de escrita (como pull requests de forks) roda em uma VM descartável. Você tem tudo isso por $39 por mês no S, trocando uma linha runs-on, sem nada para manter.
O Skipbox roda repositórios públicos?
Sim, repositórios públicos e privados igualmente. O código de pessoas sem acesso de escrita (como pull requests de forks) roda em uma VM nova, que lê o seu cache mas não pode alterá-lo; a sua própria máquina roda só o código da sua equipe.
Os minutos são mesmo ilimitados?
Sim. Os planos custam $39, $79 ou $149 por mês, cobrados em dólares americanos mensalmente, ou anualmente adiantado pelo preço de 10 meses, sem cobrança por uso. Um plano limita quantos trabalhos rodam ao mesmo tempo e o tamanho de cada um, não os minutos: um trabalho que não cabe espera até um dos que estão rodando terminar, e a espera não acrescenta nada à sua fatura. A página da sua organização no Skipbox mostra quantos trabalhos estão esperando e há quanto tempo o mais antigo espera. Um trabalho pode rodar por até 6 horas.
Como os trabalhos maiores contam nos trabalhos simultâneos?
Os trabalhos simultâneos são contados em trabalhos de 4 vCPU. Um plano roda ao mesmo tempo trabalhos até o seu total de vCPU (S 4, M 8, L 16 vCPU), então um trabalho de 8 vCPU conta como 2, e um de 16 vCPU como 4. O maior trabalho que um plano pode rodar sozinho tem o número de vCPU do plano: 4 no S, 8 no M, 16 no L. Adicione planos para rodar mais trabalhos ao mesmo tempo.
Como o Skipbox se compara aos executores do GitHub?
Cada trabalho do Skipbox S tem 4 vCPU e 16 GB; o ubuntu-latest do GitHub em um repositório privado tem 2 núcleos e 8 GB. A sua própria máquina também guarda as camadas Docker e o cache de pacotes do seu último trabalho, então um build que os usa não precisa baixá-los de novo; um trabalho hospedado pelo GitHub começa sempre em uma VM nova. docker build e docker compose build reutilizam as camadas. O builder padrão da docker/setup-buildx-action começa vazio em cada trabalho, então defina driver: docker nele para usar o cache da própria máquina. Depois que o seu primeiro trabalho rodar no Skipbox, o painel mostra o tempo dele ao lado da mediana no GitHub nos últimos 30 dias, quando o GitHub o rodou nesse período.
Meu build fica sem memória no executor do GitHub. Quanta memória o Skipbox tem?
16 GB no plano S, na sua própria máquina: 2× os 8 GB do ubuntu-latest em um repositório privado, e o mesmo que o "larger runner" do GitHub, que tem 4 núcleos. O plano S já teve 8 GB, e isso não bastava para o openai/codex (rust-v0.159.3): o cargo clippy --workspace --tests só terminou porque empurrou cerca de 14 GB para swap comprimido. Com os 16 GB de hoje, o mesmo build usa cerca de 20 MB de swap. Para um trabalho que precisa de mais, o plano L tem 32 GB.
O que o Skipbox pode acessar?
Só o que precisa para registrar executores e verificar trabalhos. Em uma organização, o app Skipbox CI pede três permissões: Self-hosted runners (escrita), para registrar no GitHub um executor para cada trabalho e removê-lo quando o trabalho termina; Actions (leitura e escrita), para ver quais trabalhos estão esperando, verificar o status deles, ler quanto tempo os seus trabalhos rodaram nos últimos 30 dias para a sua cotação e executar novamente um trabalho cuja máquina do Skipbox parou no meio; e Metadata (leitura). O app Skipbox CI nunca edita nem faz push dos seus fluxos de trabalho, e não pode ler o seu código: cada trabalho faz o checkout do seu código sozinho, na VM em que roda. Em uma conta pessoal, o GitHub só registra um executor para um repositório com a permissão Administration, que também cobre as configurações do repositório, os colaboradores e as chaves de implantação. O Skipbox (personal) a pede e a usa só para registrar e remover executores. Um recurso é a exceção, e só quando você o instala: o botão "Abrir um pull request" do painel usa um app separado, o Skipbox Migrate, que você instala só nos repositórios que escolher. Neles ele pede acesso de escrita a Contents, Workflows e Pull requests, faz push de um branch (skipbox/run-ci-on-skipbox) que muda só as linhas runs-on e abre um pull request a partir dele. Ele nunca faz merge nem mexe no seu branch padrão. Quando você entra, o Skipbox também lê o seu endereço de e-mail, para os avisos do teste e da cobrança. Como em qualquer executor, a VM de um trabalho guarda os segredos do seu fluxo de trabalho e o token do GitHub para esse trabalho, então o código que o trabalho roda pode lê-los.
Onde os trabalhos rodam?
Na máquina própria da sua organização: uma VM do tamanho do seu plano (também durante o teste), mais uma a cada plano extra. Nenhuma outra organização a usa. Ela continua ligada entre os seus trabalhos, então as imagens Docker, o cache, o seu checkout e a saída de build (o target/ do Cargo e, com o turbo 2, o cache do Turborepo) ficam para os próximos trabalhos. Ela roda em servidores que a Fluxenic, empresa por trás do Skipbox, aluga de provedores de nuvem ou opera por conta própria. A política de privacidade lista cada provedor e país. Depois de cada trabalho, as credenciais do executor, as credenciais do Git no seu checkout e os arquivos de credenciais comuns são apagados. Os trabalhos além das suas próprias máquinas, o código de pessoas sem acesso de escrita (como pull requests de forks) e todos os trabalhos com Limpar a cada trabalho rodam em uma VM nova, excluída com o disco quando o trabalho termina. Um trabalho que ainda esteja rodando depois de 6 horas é interrompido. Nada pode se conectar de fora pela internet. O envio de e-mail (porta TCP 25) é bloqueado. O resto da internet fica aberto, como nos executores hospedados pelo GitHub. O tráfego não é cobrado.
Posso recomeçar a minha máquina do zero ou rodar cada trabalho em uma VM nova?
Sim. Clique em Redefinir máquina em Planos e cobrança, a qualquer momento. Ative Limpar a cada trabalho ali, e cada trabalho roda em uma VM nova.
Podemos cancelar ou pedir reembolso?
Cancele quando quiser; o seu plano vai até o fim do mês, ou do ano, que você pagou. Se os seus trabalhos não ficarem mais rápidos no Skipbox do que eram no GitHub, você recebe de volta tudo o que pagou, nos planos mensais e anuais igualmente: peça na página Planos e cobrança da sua conta em até 30 dias do seu primeiro pagamento. O Skipbox pega o tempo mediano de cada trabalho no Skipbox e no GitHub (nos 30 dias antes de você instalar o Skipbox), pondera cada trabalho pela frequência com que rodou no GitHub e compara os dois totais; um trabalho conta depois de rodar pelo menos 3 vezes em cada um, e sem nenhum trabalho para comparar não há o que reembolsar. Se o primeiro trabalho que você rodar depois de assinar não começar em até 10 minutos, sem contar o tempo de espera atrás dos seus próprios trabalhos, devolvemos o seu pagamento integral automaticamente e encerramos o plano. Fora isso, um mês ou ano pago não é reembolsado, exceto nos casos listados nos Termos.
O que acontece quando o teste termina? Vou ser cobrado?
Nada é cobrado: o teste não pede cartão. Ele começa no seu primeiro trabalho no Skipbox, não quando você entra ou instala o app, e roda um trabalho de 4 vCPU · 16 GB por vez durante 7 dias ou 3.000 minutos, o que vier primeiro. Há 1 teste por conta e 1 por pessoa. Quando ele termina, os novos trabalhos esperam no GitHub até você escolher um plano.
Como rodo um trabalho no Skipbox e depois volto?
Troque runs-on para skipbox para mudar, e de volta para ubuntu-latest para voltar. Entre com o GitHub, instale o app Skipbox CI na sua organização ou o Skipbox (personal) na sua conta pessoal, troque a linha runs-on do trabalho para skipbox e faça commit; para uma VM maior, nos planos que incluem uma, use skipbox-8x16 ou skipbox-16x32. Para voltar, troque runs-on: skipbox de volta para runs-on: ubuntu-latest. Nada mais no seu repositório mudou.