Runners de GitHub Actions auto-alojados, na UE
Os mesmos workflows, numa máquina em Praga ou na Covilhã que é sua ao mês em vez de ao minuto - com a cache de compilação ainda quente e um endereço que uma firewall consegue mesmo autorizar.
Para quem é
Uma equipa a vigiar o contador de minutos
Um minuto de Linux de 2 núcleos custa 0,006 USD e um de 16 núcleos custa 0,042 USD, portanto a compilação em matriz que tornou a suite rápida é a mesma coisa que tornou a fatura interessante.
Um workflow que tem de chegar a algo privado
O passo de deploy precisa de falar com uma base de dados, um registo ou um equipamento que só aceita endereços conhecidos, e os runners alojados do GitHub chegam de uma gama demasiado grande para autorizar.
Uma compilação que precisa de mais do que a imagem traz
Um compilador licenciado, um emulador, 30 GB de fixtures, ou simplesmente mais disco do que o runner alojado tem - e instalá-lo de novo em cada job é a maior parte da pipeline.
O que muda quando o runner é seu
- O espaço de trabalho e as caches persistem entre jobs, portanto restaurar dependências deixa de ser o passo mais longo do workflow.
- Um IPv4 estático do AS204057 que a sua base de dados, o seu registo ou a sua VPN podem autorizar pelo endereço.
- O que instalar continua instalado - toolchains, SDK licenciados, emuladores, grandes conjuntos de fixtures, tudo o que a imagem alojada não traz.
- Runners registados ao nível do repositório, da organização ou da empresa, com as etiquetas que escolher e um workflow que os seleciona por runs-on.
- Disco e RAM à sua escolha, em vez da forma fixa em que vem um runner alojado.
- Uma máquina em Praga ou na Covilhã sob contrato cipriota, o que é uma resposta de residência de dados e não uma definição de região.
Dimensionado pelo que a pipeline faz de facto
Um serviço de runner é um job de cada vez, portanto aqui a concorrência é uma contagem de processos de runner e não um escalão de plano - vários num host, cada um na sua própria pasta, é a forma normal. Dimensione pelo job mais pesado e não pela média, e deixe folga de disco: o espaço de trabalho, a cache de ferramentas e as camadas de contentor vivem todos lá, e é essa persistência a razão para auto-alojar. A metade honesta do negócio: um host mensal fixo custa o mesmo numa semana sem pushes, onde os minutos alojados não custam nada. Compensa assim que a pipeline corre quase todos os dias.
Como instalar um runner de GitHub Actions num host novo
Linux x64, pela ordem que o GitHub documenta. O token de registo é gerado por runner e expira uma hora depois de abrir a página, portanto vá buscá-lo em último lugar.
-
Criar um utilizador sem privilégios para ele
sudo adduser --disabled-password --gecos "" runner sudo -iu runnerO runner executa o que um workflow lhe mandar, portanto não deve ser root nem partilhar a pasta pessoal com mais nada. Tudo o que se segue corre como este utilizador.
-
Descarregar e desempacotar o runner
mkdir actions-runner && cd actions-runner curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c tar xzf ./actions-runner-linux-x64-2.336.0.tar.gzEssa versão e essa soma de verificação são as publicadas com a release v2.336.0. Veja se há uma mais recente na página de releases antes de copiar isto: o runner atualiza-se sozinho depois, mas o primeiro download é seu para verificar.
-
Configurá-lo contra um repositório ou uma organização
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,euVá buscar o token a Settings, depois Actions, depois Runners, depois New self-hosted runner - é limitado no tempo e expira uma hora depois de emitido. Aponte o URL à organização em vez do repositório para partilhar um runner por vários repositórios.
-
Correr como serviço
sudo ./svc.sh install runner sudo ./svc.sh start sudo ./svc.sh statusO svc.sh recebe o utilizador com que o serviço deve correr, e foi por isso que o utilizador runner foi criado primeiro. Use antes o ./run.sh se só quiser ver um job aterrar antes de se comprometer com um serviço.
-
Impedir que o needrestart mate jobs a meio
echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.confNo Debian e no Ubuntu, o needrestart reinicia serviços cujas bibliotecas foram atualizadas - incluindo um runner a meio de um job. O GitHub documenta exatamente este ficheiro como a forma de o excluir.
-
Apontar um workflow para ele
name: smoke on: [push] jobs: build: runs-on: [self-hosted, linux, x64, eu] steps: - uses: actions/checkout@v6 - run: cat /etc/os-releaseO runs-on corresponde a todas as etiquetas da lista, portanto um job que pede quatro etiquetas só aterra num runner que as tenha todas. Se ficar em fila, falta uma etiqueta - e um job em fila há mais de 24 horas falha.
Verificado na documentação oficial em 2026-08-15 — ler a fonte
O que não somos
- Não somos o GitHub. O GitHub, o GitHub Actions e o runner são deles, e nada nesta página tem o aval deles. Vendemos a máquina onde o runner corre.
- Isto não substitui o seu plano do GitHub. Os runners auto-alojados não custam minutos de Actions, que é o objetivo, mas as licenças, o armazenamento e tudo o resto continuam na fatura deles.
- Não gerimos o runner a não ser que peça. Instala-o você, ou acrescenta o nosso serviço de administração e mantemo-lo atualizado, registado e vigiado.
- Os runners auto-alojados estão documentados como pouco adequados a repositórios públicos: um fork pode propor uma alteração ao workflow, e esse workflow alterado correria na sua máquina. Mantenha-os em repositórios privados a não ser que já tenha pensado bem nisso.
- Aqui não há plano de controlo com autoescalonamento. Se quer runners criados e destruídos por job, isso é o Actions Runner Controller num cluster Kubernetes - que alojamos com gosto, noutra página.
As partes que as equipas descobrem tarde
- Um serviço de runner corre um job de cada vez. A concorrência vem de instalar vários, cada um na sua pasta com o seu próprio serviço, não de uma definição.
- O token de registo expira uma hora depois de emitido, portanto gere-o quando estiver pronto para correr o config.sh e não no início da tarde.
- As etiquetas são todo o mecanismo de encaminhamento. O runs-on corresponde a cada etiqueta da lista, portanto uma gralha não dá erro - o job simplesmente espera, e falha ao fim de 24 horas em fila.
- O runner precisa de lttng-ust, OpenSSL, Kerberos, zlib e libicu presentes. O Debian e o Ubuntu trazem-nos; uma imagem de contentor mínima muitas vezes não.
- x64 e ARM64 são suportados em Linux, e ARM32 só em Linux. Debian 10 e posteriores e Ubuntu 20.04 e posteriores são as bases documentadas.
- Tudo o que o workflow deixa para trás fica no disco - é essa a vantagem, e é também por isso que um runner auto-alojado quer uma tarefa de limpeza agendada e um snapshot.
Minutos de CI alojados contra um runner seu
| Minutos de CI alojados pelo fornecedor | Um runner na DCXV | |
|---|---|---|
| O que paga | Cada minuto de cada job, enquanto o projeto existir | Um host mensal fixo, faça a pipeline o que fizer nesse mês |
| Uma compilação que fica mais lenta | Custa mais em cada mês que continue lenta | Não custa mais nada - a máquina já está paga |
| Cache de camadas Docker | Fria em cada job a não ser que a envie e a descarregue você mesmo | Quente em NVMe local, entre jobs e entre dias |
| Concorrência | Um escalão de plano que se sobe | Um número que define no seu próprio ficheiro de configuração |
| Onde aterra o checkout | Uma frota partilhada, muitas vezes numa região que não consegue fixar | Uma máquina em Praga ou na Covilhã, sob contrato cipriota |
| Endereço de saída | Uma gama partilhada enorme que nada consegue autorizar | Um IPv4 estático do AS204057, seu para autorizar |
| O que a máquina pode conter | O que a imagem do runner por acaso traga | Qualquer toolchain, licença ou conjunto de fixtures que instale uma vez |
Como isto arranca no seu host
Diga-nos o que faz a pipeline
O job mais pesado que corre hoje, quantos quer em simultâneo, e se constrói imagens de contentor. Isso chega para dimensionar um host sem adivinhar.
Entregamos-lhe a máquina
Praga ou Covilhã, acesso root e um IPv4 estático, em menos de dez minutos. Traga a sua própria imagem se o runner já vier lá dentro.
Siga o passo a passo desta página
É a sequência do fabricante, tirada da documentação atual e não de um artigo de blogue, e demora poucos minutos num host limpo.
Faça um snapshot e acrescente o segundo
Faça um snapshot assim que a primeira pipeline estiver verde, para que a máquina seguinte seja um restauro e não uma reconstrução. Um conjunto cresce acrescentando hosts, não tornando um enorme.
Porquê escolher-nos
- Instalações certificadas Tier III, SLA da instalação de 99,982 %
- Rede própria, AS204057, IPv4 e IPv6
- Suporte 24/7/365 com cerca de 10 minutos de resposta média
- Empresa cipriota, jurisdição da UE, conforme o RGPD desde 2007
FAQ
- Quanto custam os runners alojados do GitHub face a auto-alojar?
O GitHub fatura os runners Linux alojados ao minuto: 0,006 USD para 2 núcleos, 0,012 para 4, 0,022 para 8 e 0,042 para 16, com Windows a 0,010 para 2 núcleos e macOS a 0,062 para uma máquina de 3 ou 4 núcleos. Os runners auto-alojados não consomem minutos de Actions. Um host aqui começa em 16,49 EUR por mês, aproximadamente o que custam 2.700 minutos num runner alojado de 2 núcleos - portanto o ponto de viragem anda pelas 45 horas de compilação por mês
- Como configuro um runner de GitHub Actions auto-alojado?
Crie um utilizador sem privilégios, descarregue o arquivo do runner para linux-x64 das releases do actions/runner e verifique a soma de verificação, corra ./config.sh com o URL do seu repositório ou organização e o token de registo de Settings, Actions, Runners, e depois instale-o como serviço com sudo ./svc.sh install e arranque-o. Os comandos exatos estão nesta página. O token de registo expira uma hora depois de emitido
- Quantos jobs pode um runner correr ao mesmo tempo?
Um. Um serviço de runner aceita um único job de cada vez, portanto concorrência significa instalar vários serviços de runner no host, cada um na sua própria pasta. É por isso que o dimensionamento desta página conta serviços de runner e não jobs, e por isso uma máquina de 8 vCPU leva com folga uma compilação em matriz pequena
- Que sistemas operativos e arquiteturas são suportados?
Em Linux, Debian 10 e posteriores, Ubuntu 20.04 e posteriores, RHEL 8 e posteriores, CentOS 8 e posteriores, Fedora 29 e posteriores, openSUSE 15.2 e posteriores e os seus parentes, em x64, ARM64 e ARM32. O runner precisa ainda de lttng-ust, OpenSSL, Kerberos, zlib e libicu, que o Debian e o Ubuntu trazem de série
- É seguro usar um runner auto-alojado num repositório público?
O GitHub desaconselha-o, e a razão é concreta: qualquer pessoa pode abrir um pull request que altere o ficheiro do workflow, e esse workflow alterado correria na sua máquina. Mantenha os runners auto-alojados em repositórios privados a não ser que tenha lido isso a fundo e montado isolamento a sério. Tudo o que um job deixa para trás persiste ainda no disco, o que é uma vantagem para a cache e um risco para os segredos
- Pode um runner servir vários repositórios?
Pode. Registe-o ao nível da organização em vez do repositório e qualquer repositório da organização poderá selecioná-lo, usando etiquetas no runs-on para encaminhar o trabalho. Um job que peça uma etiqueta que nenhum runner tem fica simplesmente à espera, e falha ao fim de 24 horas em fila - é assim que se parece uma gralha no runs-on
Se precisar de assistência ou tiver perguntas adicionais, por favor contacte os gestores ou escreva para a equipa de suporte em support@dcxv.com
Pronto para começar?
Faturação mensal, sem taxa de instalação, sem fidelização