Como rodo um runner auto-hospedado do GitHub Actions em um VPS?

Provisione um VPS Linux (Small — 4 vCPU / 4 GB — é o padrão sensato), instale o pacote do runner em Settings → Actions → Runners do seu repositório, registre-o com o token que o GitHub fornece e inicie-o como serviço. Os passos completos para copiar e colar estão abaixo; você obtém root em cerca de um minuto.

Posso rodar o runner no Docker?

Sim. Rode a imagem oficial do runner (ou a sua) em um contêiner, ou use-a para dar a cada job um ambiente isolado e descartável. IP dedicado não é necessário — o runner só faz conexões de saída ao GitHub, então um plano NAT também serve.

Como mantenho o runner rodando como serviço?

O runner traz um script auxiliar svc.sh que instala uma unidade systemd: ./svc.sh install && ./svc.sh start. Depois ele sobrevive a reinicializações e reinicia em caso de falha. O guia abaixo mostra os comandos exatos.

Um runner auto-hospedado é mais barato que os minutos hospedados pelo GitHub?

Para CI pesado ou frequente, sim. Runners hospedados pelo GitHub cobram por minuto acima da cota gratuita; um VPS de US$ 8/mês roda minutos ilimitados por uma taxa fixa e permanece 'quente' (sem cold start, dependências em cache). Um repositório movimentado costuma pagar a máquina sozinho.

Vocês pedem documento ou cartão de crédito?

Não. Registro por e-mail, pagamento em USDC ou USDT. Sem documentos, sem cartão, nunca KYC.

VPS para runners auto-hospedados do GitHub Actions

Rode seu próprio runner auto-hospedado do GitHub Actions em um VPS — CI mais rápido, sem cobrança por minuto, controle total do ambiente de build. Pagamento em cripto, sem KYC. A partir de US$ 8/mês.

Runners hospedados pelo GitHub são convenientes até a fatura ou o tempo de espera começarem a doer. Acima da cota gratuita você paga por minuto, cada job inicia 'a frio' e rebaixa as dependências a cada execução. Um runner auto-hospedado no seu próprio VPS inverte os três pontos: custo mensal fixo, uma máquina 'quente' com seus caches já no disco e um ambiente de build que você controla por completo — versões específicas de ferramentas, mais RAM, um cache de camadas do Docker que realmente persiste.

Um runner só precisa alcançar o GitHub em saída, então roda nos nossos planos mais baratos, paga-se em cripto e não exige KYC.

O que um runner precisa

CPU e RAM para seus builds. Small (US$ 8/mês — 4 vCPU, 4 GB RAM, 35 GB NVMe) é o padrão confortável para a maioria dos CI: builds Node/Go/Rust, suítes de teste, builds de imagem Docker. Compilação pesada ou jobs paralelos? Suba para Medium ou um plano Pro.
Disco NVMe para caches. Todo o sentido do auto-hospedar é a persistência — caches de dependências, camadas do Docker e artefatos de build ficam no disco entre execuções. O NVMe mantém as restaurações rápidas.
IP dedicado não é necessário. O runner disca para o GitHub por HTTPS; nenhum acesso de entrada é necessário. Um plano NAT (a partir de US$ 3/mês) basta. Pegue um IP dedicado só se também hospedar algo que sirva tráfego.

Configurar um runner (Ubuntu 24.04)

Crie o runner no seu repositório (ou organização): Settings → Actions → Runners → New self-hosted runner → Linux. O GitHub mostra um comando de download e um token de registro de uso único. No VPS:

# como usuário não-root (o runner se recusa a rodar como root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# registrar com a URL + o token da interface do GitHub
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Mantê-lo rodando como serviço

Não rode ./run.sh em um terminal — instale o runner como serviço systemd para que ele sobreviva a reinicializações:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

O runner agora aparece como Idle na interface do GitHub e assume qualquer job que o mire.

Usar a partir de um workflow

Aponte um job para o seu runner com runs-on:

jobs:
  build:
    runs-on: self-hosted        # ou um rótulo personalizado definido no registro
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Jobs baseados em Docker

Instale o Docker uma vez e seus workflows poderão construir imagens ou rodar contêineres de serviço, com o cache de camadas persistindo entre execuções:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # permitir ao runner usar Docker sem sudo

Para isolamento descartável por job, rode o próprio runner dentro de um contêiner e recrie-o a cada execução — um padrão comum para builds não confiáveis ou em matriz.

Por que EQVPS para CI

Custo fixo, minutos ilimitados. Sem medição por minuto — um pipeline movimentado custa o mesmo que um ocioso.
Caches 'quentes'. Dependências e camadas do Docker ficam no NVMe entre execuções; os builds ficam mais rápidos, não mais lentos.
Root em ~60 segundos, imagens limpas. Ubuntu, Debian e mais via cloud-init; instale exatamente a toolchain de que precisa.
Sem KYC, pagamento em cripto. E-mail para se cadastrar, USDC/USDT para pagar. Suba runners extras para picos de release e cancele-os depois.

Guia completo de configuração passo a passo →