# Como configuro um runner auto-hospedado do GitHub Actions em um servidor dedicado alugado?

> Configure um runner auto-hospedado do GitHub Actions em 8 passos com a documentação oficial. Cripto, sem KYC, a partir de US$ 91,65.

- URL: https://lumenfer.com/pt/github-actions-runner-dedicated-server/
- Última atualização: 2026-11-01
- Editor: Lumenfer (https://lumenfer.com)

Registre um runner em uma máquina Linux alugada, execute-o como serviço sob o próprio usuário e mantenha código não confiável longe dele. Todos os comandos e regras abaixo vêm da documentação do GitHub.

**Resposta rápida — Como configuro um runner auto-hospedado do GitHub Actions em um servidor dedicado alugado?**

Para configurar um runner auto-hospedado do GitHub Actions em um servidor dedicado alugado, crie primeiro um usuário não-root. Depois abra Settings → Actions → Runners → New self-hosted runner e execute os comandos que o GitHub mostra, depois `sudo ./svc.sh install` para mantê-lo em execução. Use-o apenas em repositórios privados. Servidores **Lumenfer** começam em US$ 91,65 por 30 dias, pagos em cripto e sem KYC.

## O que o runner precisa, conforme a referência do GitHub

| Atributo | Valor |
| --- | --- |
| Rede | HTTPS de saída na porta 443 para github.com, api.github.com e *.actions.githubusercontent.com; pelo menos 70 kbit/s em cada direção |
| Sistemas Linux | Ubuntu 20.04 ou posterior e Red Hat Enterprise Linux 8 ou posterior, entre outros, em x64 |
| Jobs em contêiner | Uma máquina Linux com Docker instalado |
| Atualizações do runner | Automáticas quando um job é atribuído; você precisa atualizar em até 30 dias após um novo lançamento |
| Limites de jobs | Até 5 dias por job; um job na fila por 24 horas é cancelado |
| Runners offline | Removido após 14 dias sem conexão; runners efêmeros após 1 dia |
| Imagens em Lumenfer | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 e Proxmox VE 9 |
| Login | You log in as root over SSH. Paste a public key when ordering and password logins stay disabled, or skip it and receive a temporary root password with the server, to replace on your first login |
| Setup | Poucos minutos depois que o pagamento é confirmado, e nunca mais de uma hora |

## O que eu preciso antes de instalar o runner?

**Você precisa de direitos de administrador no GitHub e de root em uma máquina Linux.** Para um runner de repositório, o GitHub exige que você seja o proprietário do repositório, um proprietário da organização ou um administrador do repositório. Um runner de toda a organização precisa de um proprietário da organização.

No lado do servidor, peça uma imagem Ubuntu 24.04 LTS ou Debian com sua chave pública SSH. Seu servidor entra no ar poucos minutos depois que o pagamento é confirmado, e a espera nunca passa de uma hora; o painel acompanha a preparação e depois mostra o endereço IP assim que a máquina está rodando. O endereço IP aparece no seu dashboard quando a máquina estiver pronta.

Escolha o tamanho pelo seu job mais pesado, não pela média. Nosso [guia de hardware para servidores de build](https://lumenfer.com/pt/build-server-hardware/ "What hardware a build server needs: cores, RAM and NVMe") explica como compiladores e linkers usam núcleos e memória.

## Posso usar um runner auto-hospedado em um repositório público?

**Evite: o GitHub recomenda runners auto-hospedados apenas para repositórios privados.** Qualquer pessoa pode fazer fork de um repositório público e abrir um pull request. Esse pull request pode executar código na sua máquina.

A referência de segurança do GitHub deixa claro o risco. Um runner pode ser comprometido de forma persistente por código de workflow não confiável. Esse código pode então alcançar segredos e o `GITHUB_TOKEN`. Segredos de ambiente e revisores obrigatórios não isolam a máquina em si.

- **Restrinja o token.** Defina a permissão padrão de `GITHUB_TOKEN` como somente leitura para o conteúdo do repositório e conceda mais por job.
- **Evite gatilhos privilegiados.** Nunca combine `pull_request_target` ou `workflow_run` com um checkout de código de pull request não confiável.
- **Agrupe seus runners.** Runners de organização podem receber jobs de muitos repositórios. Grupos de runners mantêm um comprometimento dentro de um limite.
- **Mantenha segredos fora do disco.** O GitHub pede que você minimize o material sensível armazenado no runner.

## Como instalo o runner, passo a passo?

Estes passos seguem três páginas do GitHub Docs, sobre adicionar runners, executá-los como serviço e usá-los em workflows, lidas em 1º de novembro de 2026. Cada um roda via SSH.

1. **Peça o servidor com sua chave SSH** — Escolha Ubuntu 24.04 LTS ou Debian no checkout e cole sua chave pública. Os logins por senha ficam então desativados.
2. **Atualize o sistema e adicione um usuário para o runner** — Execute apt update && apt full-upgrade e depois crie um usuário sem privilégios, como gh-runner. Jobs nunca devem rodar como root.
3. **Instale o Docker somente se os jobs usarem containers** — O GitHub precisa do Docker no Linux para container actions e service containers. A documentação do Docker avisa que o grupo docker concede privilégios de nível root.
4. **Abra a página New self-hosted runner** — No repositório, vá em Settings → Actions → Runners → New self-hosted runner e escolha Linux e x64. As organizações usam primeiro New runner.
5. **Execute os comandos do GitHub como o usuário do runner** — Cole as linhas de download, checksum e ./config.sh --url … --token … na ordem mostrada. O token de registro expira após uma hora.
6. **Instale o runner como serviço** — Na pasta do runner, execute sudo ./svc.sh install gh-runner e depois sudo ./svc.sh start e sudo ./svc.sh status. Ele agora sobrevive a reinicializações.
7. **Aponte um workflow para ele** — Defina runs-on: [self-hosted, linux, x64]. Um runner precisa ter todos os labels listados para receber o job.
8. **Reforce as configurações do repositório** — Deixe o GITHUB_TOKEN como somente leitura por padrão e limite quais repositórios podem usar o runner. Depois execute um job de teste.

*Passos 2, 5 e 6 no Ubuntu ou Debian (URL e token vêm da sua página New runner)*

```bash
# step 2, as root: update and create the runner user
apt update && apt full-upgrade -y
adduser --disabled-password --gecos "" gh-runner

# step 5, as gh-runner, in the folder where you ran GitHub's download lines
./config.sh --url https://github.com/OWNER/REPO --token TOKEN
# for a runner that takes one job, then de-registers:
# ./config.sh --url https://github.com/OWNER/REPO --token TOKEN --ephemeral

# step 6, from the same folder, with sudo rights
sudo ./svc.sh install gh-runner
sudo ./svc.sh start
sudo ./svc.sh status
```

*Passo 7: um job que roda no servidor alugado*

```yaml
permissions:
  contents: read

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v7
      - run: make -j"$(nproc)" test
```

## Devo usar runners efêmeros em um único servidor alugado?

**Sim, para qualquer coisa além de código interno confiável: o GitHub recomenda runners efêmeros, que recebem um job e depois se desregistram.** Adicione `--ephemeral` quando você executar `config.sh`. Sua própria automação então limpa o workspace e registra um runner novo.

O GitHub também oferece runners just-in-time. O endpoint REST `POST /repos/{owner}/{repo}/actions/runners/generate-jitconfig` retorna uma configuração de um job. Para o registro clássico, `POST /repos/{owner}/{repo}/actions/runners/registration-token` retorna um token válido por uma hora.

**Runners de um job no mesmo host físico não são um estado limpo.** O GitHub avisa que reutilizar hardware para runners just-in-time pode expor informações do ambiente. Em bare metal, dê a cada job uma máquina virtual ou um container descartável.

- **Máquinas virtuais.** Peça a imagem Proxmox VE e clone uma VM de template por job. Veja [como montar um cluster Proxmox em servidores alugados](https://lumenfer.com/pt/proxmox-cluster-dedicated-servers/ "Proxmox cluster with rented dedicated servers").
- **Kubernetes.** O Actions Runner Controller do GitHub é um operador Kubernetes que escala runners auto-hospedados. Veja [como rodar Kubernetes em bare metal](https://lumenfer.com/pt/kubernetes-bare-metal/ "Kubernetes on bare metal servers").
- **Logs.** Um runner de um job não deixa nada para inspecionar depois, então o GitHub pede que você encaminhe os logs dele para armazenamento externo primeiro.

## Quantos runners um servidor aguenta?

**Um processo de runner recebe um job, então registre tantos runners quantos jobs paralelos você quiser, cada um em sua própria pasta com seu próprio serviço.** Divida a máquina pelo seu job mais pesado. Uma divisão comum é um runner a cada 4 a 8 threads, com RAM para o pior passo de link.

A tabela relaciona cada plano a um ponto de partida razoável. Ajuste após uma semana observando `htop` e os tempos dos jobs.

### Planos Lumenfer como hosts de CI runner

| Plano | CPU | Núcleos | Memória | Discos | A cada 30 dias | Bom começo |
| --- | --- | --- | --- | --- | --- | --- |
| Lumen 6 | AMD EPYC 4244P | 6 núcleos / 12 threads | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | 1 a 2 runners: lint, testes unitários, serviços pequenos |
| Lumen 8 | AMD Ryzen 7 9700X | 8 núcleos / 16 threads | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | 2 a 4 runners: builds em Go, Rust ou Java |
| Lumen 16 | AMD Ryzen 9 9950X | 16 núcleos / 32 threads | 128 GB DDR5 | 2 × 1.92 TB NVMe | $205.27 | 4 a 8 runners, ou um build grande em C++ |
| Lumen 24 | AMD EPYC 9254 | 24 núcleos / 48 threads | 256 GB DDR5 ECC | 2 × 1.92 TB NVMe | $356.25 | VMs de runner no Proxmox, com memória ECC |
| Lumen 32 | AMD EPYC 9354 | 32 núcleos / 64 threads | 384 GB DDR5 ECC | 2 × 3,84 TB NVMe | $749.67 | Um pool de runners para uma organização inteira |

## O que os runners hospedados pelo GitHub fazem que agora eu faço sozinho?

**A máquina limpa, as atualizações e a recuperação: o GitHub torna você responsável pelo sistema operacional e por todo o restante do software.**

- **Crescimento do disco.** Workspaces, imagens Docker e caches se acumulam entre jobs. Agende uma limpeza, ou o NVMe enche durante um release.
- **Atualizações do runner.** O runner se atualiza sozinho quando recebe um job. Se você registrar com `--disableupdate`, ainda precisa atualizar em até 30 dias.
- **Bloqueios.** Não há console IPMI nem KVM-over-IP para clientes: você solicita reinicializações e reinstalações no painel e a equipe as executa. Teste mudanças de firewall com uma segunda sessão SSH aberta.
- **E-mails dos builds.** SMTP de saída na porta 25 é bloqueado em todos os servidores e nunca é desbloqueado; as portas de submissão 465 e 587 para provedores de e-mail continuam abertas.
- **Dados.** Backups não estão incluídos: mantenha cópias dos seus dados em outro lugar.

**Na verificação de Lumenfer sobre 30 October 2026, vendedores de servidores dedicados informaram prazos de setup a partir de 30 minutos a 10 dias úteis, com mediana de 24 horas.** Lumenfer fica no lado rápido: um host de runner entra no ar minutos depois da confirmação do pagamento, com uma hora como limite. Os custos são comparados minuto a minuto em [runner auto-hospedado vs custo do GitHub-hosted](https://lumenfer.com/pt/self-hosted-runner-vs-github-hosted-cost/ "Is a rented server cheaper than GitHub-hosted runners?"), e cada plano está na [página de preços da Lumenfer](https://lumenfer.com/pt/pricing/ "Lumenfer plans and prices per 30 days").

## Qual plano deve hospedar meus runners?

Máquinas dedicadas, um cliente cada, cobradas de um saldo em cripto. Amsterdã (Países Baixos), Reykjavik (Islândia), Zurique (Suíça) e Bucareste (Romênia): todos os cinco planos nas quatro cidades, um preço em todo lugar.

| Plano | Quantidade | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 núcleos · 32 GB DDR5 | US$ 91,65 | US$ 247,45 (−10%) | US$ 439,92 (−20%) | US$ 769,86 (−30%) |
| Lumen 8 | 8 núcleos · 64 GB DDR5 | US$ 109,37 | US$ 295,29 (−10%) | US$ 524,97 (−20%) | US$ 918,70 (−30%) |
| Lumen 16 | 16 núcleos · 128 GB DDR5 | US$ 205,27 | US$ 554,22 (−10%) | US$ 985,29 (−20%) | US$ 1.724,26 (−30%) |

Em todos os planos: 2022+ CPU · DDR5 · Somente NVMe · RAID 1 · IPv4 dedicado · Sem KYC

**Antes de pagar**

- Recarga mínima de US$ 1. Recarregue uma vez com cripto e depois compre qualquer plano usando seu saldo.
- Os créditos no seu saldo não expiram e renovam qualquer um dos seus servidores. Quando um depósito é feito apenas para atingir o mínimo, a parte não utilizada é devolvida mediante solicitação em até 30 dias após o pagamento, em USDT ou USDC. O restante do saldo não é pago, a menos que a lei exija.
- Creditado assim que seu pagamento é verificado na blockchain. Tempo habitual de confirmação da rede: BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min · XMR ≈ 20 min

## GitHub runner auto-hospedado em um servidor alugado: FAQ

### Posso rodar o GitHub runner como root?

Não. Crie um usuário dedicado e instale o serviço para ele com `sudo ./svc.sh install USERNAME`, como mostra a página de serviço do GitHub. Um job rodando como root pode alterar o host para todos os jobs seguintes, e para você também.

### O runner precisa de alguma porta de entrada?

A lista de requisitos de comunicação do GitHub indica HTTPS de saída na porta 443 para os domínios dele, além de pelo menos 70 kbit/s em cada direção. Na entrada, você pode fechar tudo exceto SSH. O runner abre todas as conexões sozinho, de saída.

### Um servidor pode atender vários repositórios?

Sim, registre o runner no nível da organização e atribua-o a um grupo de runners. O GitHub avisa que runners de organização podem receber jobs de muitos repositórios, então um grupo limita até onde um job ruim chega.

### O que acontece se meu servidor reiniciar ou ficar offline?

O serviço inicia de novo depois de um reboot. Os jobs ficam na fila e são cancelados após 24 horas. Um runner que fica desconectado por mais de 14 dias é removido do GitHub e precisa ser registrado novamente.

### Posso hospedar GitLab runners ou agentes Jenkins do mesmo jeito?

Sim. Qualquer agente de CI Linux roda no servidor com acesso root. As regras de segurança valem igual: código não confiável vai para uma VM ou container descartável, nunca para o próprio host.

### Como faço o pagamento, e vocês precisam da minha identidade?

Sem KYC: nunca pedimos um documento de identidade, uma selfie, documentos, um cartão ou um número de telefone. Recarregue um saldo em BTC, USDT, USDC, ETH, SOL, LTC, XMR (mínimo de US$ 1) e faça pedidos a partir dele por 30 dias, 3 meses, 6 meses ou 12 meses.

## Fontes

1. [Adding self-hosted runners](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners) — GitHub Docs (read 2026-11-01)
2. [Configuring the self-hosted runner application as a service](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application) — GitHub Docs (read 2026-11-01)
3. [Using self-hosted runners in a workflow](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow) — GitHub Docs (read 2026-11-01)
4. [Self-hosted runners reference (requirements, autoscaling, ephemeral runners, communication)](https://docs.github.com/en/actions/reference/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
5. [Self-hosted runners](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
6. [Secure use reference](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub Docs (read 2026-11-01)
7. [Removing self-hosted runners](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/remove-runners) — GitHub Docs (read 2026-11-01)
8. [Actions limits](https://docs.github.com/en/actions/reference/limits) — GitHub Docs (read 2026-11-01)
9. [REST API endpoints for self-hosted runners](https://docs.github.com/en/rest/actions/self-hosted-runners) — GitHub Docs (read 2026-11-01)
10. [Actions Runner Controller](https://docs.github.com/en/actions/concepts/runners/actions-runner-controller) — GitHub Docs (read 2026-11-01)
11. [Linux post-installation steps for Docker Engine](https://docs.docker.com/engine/install/linux-postinstall/) — Docker Docs (read 2026-11-01)
12. [actions/checkout (README usage)](https://github.com/actions/checkout) — GitHub (read 2026-11-01)

---

Lumenfer: A Lumenfer aluga servidores bare-metal de geração atual em Amsterdã, Reykjavik, Zurique e Bucareste, pagos com cripto e sem KYC: sem documento, sem selfie, sem papelada. Cada máquina tem uma CPU lançada em 2022 ou depois, memória DDR5 e unidades NVMe, e é alugada inteira para um único cliente com acesso root. É operada pela DomaineGoat LLC, uma empresa do Panamá que ignora notificações DMCA, responde apenas à lei panamenha, permite Tor exit relays e não mantém logs. No prazo de 30 dias, cada plano custa pelo menos 25% menos que um servidor comparável de geração atual, nomeado, de 13 hosts cripto sem KYC, consultados em 30 de outubro de 2026.