Woodpecker CI, sem qualquer SaaS pelo meio
Servidor e agentes numa máquina pequena em Praga ou na Covilhã, ligados à sua própria forja - a versão de CI em que nada da pipeline sai de uma infraestrutura que consegue nomear.
Para quem é
Uma equipa que já auto-aloja tudo o resto
A forja é sua, o registo é seu, o destino de deploy é seu - e o CI é o único salto que ainda sai do edifício, precisamente o salto que guarda o código.
Uma instalação de Drone que deixou de andar
O Woodpecker é o fork que continuou e se manteve Apache-2.0. A migração é pequena; a pergunta é sobre o que o correr.
Uma equipa pequena que quer que o CI seja aborrecido
Dois contentores, um ficheiro YAML por repositório, nenhum plano de controlo para aprender e nenhum contador ao minuto para vigiar. Só precisa de um sítio onde viver.
O que esta forma lhe dá
- Servidor e agente como dois contentores num host, pequeno o suficiente para que o CI deixe de ser um projeto de infraestrutura.
- Qualquer forja que o Woodpecker suporte - GitHub, GitLab, Gitea, Forgejo ou Bitbucket - incluindo uma que aloje você mesmo na mesma rede.
- Agentes acrescentados mais tarde como hosts separados, todos a autenticar-se no mesmo servidor, quando uma máquina deixa de chegar.
- Apache-2.0 de ponta a ponta, para que nada na pipeline dependa de um fornecedor decidir manter um plano gratuito.
- Um IPv4 estático do AS204057, para que o webhook da forja e o destino de deploy tenham ambos um endereço em que confiar.
- NVMe local para o espaço de trabalho e para a cache de camadas Docker, quente entre pipelines.
Dimensionado pelo que a pipeline faz de facto
O Woodpecker em si é leve: o servidor é um pequeno processo Go com base de dados embutida até o apontar ao Postgres, e o agente é um supervisor que arranca contentores. O que consome o host é a compilação, exatamente como com qualquer outro runner - dimensione portanto a máquina pelo job mais pesado, e dê espaço ao disco para a cache de camadas que torna rápida a segunda pipeline. O tamanho de entrada abaixo leva servidor e agente juntos com folga para uma equipa pequena. A única ressalva honesta: um host mensal fixo custa o mesmo numa semana sem pushes, onde os minutos de CI alojados não custam nada.
Como instalar o Woodpecker CI com Docker Compose
Servidor e agente num host, ligados ao GitHub neste exemplo. Troque o bloco da forja pelas variáveis do Gitea, Forgejo, GitLab ou Bitbucket se a sua forja for uma dessas.
-
Instalar o Docker e o Compose
sudo apt install docker.io docker-compose-v2 sudo systemctl enable --now dockerAmbos os contentores e cada passo da pipeline correm neste daemon, portanto é a única dependência de que o host precisa.
-
Registar uma aplicação OAuth na sua forja
# GitHub: Settings -> Developer settings -> OAuth Apps -> New OAuth App # Homepage URL: https://ci.example.com # Authorization callback: https://ci.example.com/authorizeO Woodpecker autentica os utilizadores através da forja e lê repositórios com essa autorização, portanto o id de cliente e o segredo que ela devolve são o que o servidor precisa. Cada forja suportada tem um formulário equivalente.
-
Gerar o segredo partilhado do agente
openssl rand -hex 32O servidor e os agentes autenticam-se um ao outro com esta cadeia, e a documentação do Woodpecker nomeia exatamente este comando para a produzir. Mantenha-a fora do ficheiro compose - ponha-a num ficheiro .env ao lado.
-
Escrever o ficheiro compose
services: woodpecker-server: image: woodpeckerci/woodpecker-server:v3 ports: - 8000:8000 volumes: - woodpecker-server-data:/var/lib/woodpecker/ environment: - WOODPECKER_OPEN=true - WOODPECKER_HOST=${WOODPECKER_HOST} - WOODPECKER_GITHUB=true - WOODPECKER_GITHUB_CLIENT=${WOODPECKER_GITHUB_CLIENT} - WOODPECKER_GITHUB_SECRET=${WOODPECKER_GITHUB_SECRET} - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET} woodpecker-agent: image: woodpeckerci/woodpecker-agent:v3 command: agent restart: always depends_on: - woodpecker-server volumes: - woodpecker-agent-config:/etc/woodpecker - /var/run/docker.sock:/var/run/docker.sock environment: - WOODPECKER_SERVER=woodpecker-server:9000 - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET} volumes: woodpecker-server-data: woodpecker-agent-config:Este é o exemplo oficial. WOODPECKER_HOST é o URL público a que chegam utilizadores e webhooks, a porta 8000 é a interface web e a 9000 é a porta gRPC onde os agentes se ligam. WOODPECKER_OPEN=true deixa entrar qualquer pessoa com conta na forja - desligue-o assim que a sua equipa estiver registada.
-
Arrancar
docker compose up -d docker compose logs -f woodpecker-agentO agente liga-se ao servidor com o segredo partilhado e regista-se sozinho no primeiro contacto. Se entrar em ciclo com um erro de autenticação, os dois segredos não coincidem - quase sempre porque o ficheiro .env não foi lido.
-
Acrescentar uma pipeline
when: - event: push steps: - name: smoke image: alpine:latest commands: - cat /etc/os-release - echo "built on $CI_MACHINE"Faça commit disso como .woodpecker.yaml, ative o repositório na interface web para que o webhook seja criado, e faça push. Cada passo é um contentor, e é por isso que o agente precisa do socket do Docker.
Verificado na documentação oficial em 2026-08-15 — ler a fonte
O que não somos
- Não somos o projeto Woodpecker. O Woodpecker CI é um projeto Apache-2.0 independente e nada aqui tem o aval dele. Vendemos a máquina onde corre.
- Não alojamos a sua forja nesta página. Gitea, Forgejo ou um GitLab autogerido ao lado é um segundo servidor simples, mas é outro tamanho e outro orçamento.
- Não escrevemos as suas pipelines. O YAML é seu; o host, a rede e o endereço são nossos.
- O Woodpecker não é gerido por si por omissão. Corre os dois contentores você, ou acrescenta o nosso serviço de administração e mantemo-los atualizados e copiados.
- Montar o socket do Docker dentro do agente dá aos passos da pipeline imenso poder sobre o host. É assim que este desenho funciona, e é uma razão para manter o agente numa máquina que não faz mais nada.
As partes que as equipas descobrem tarde
- O WOODPECKER_AGENT_SECRET tem dois modos. O mesmo valor no servidor e em todos os agentes é um token de sistema; um token por agente sai de registar primeiro o agente na interface, que é o que quer assim que mais do que uma equipa consegue chegar ao host.
- Toda a variável sensível tem também uma forma _FILE, para que o segredo possa ser lido de um ficheiro montado em vez de estar no ficheiro compose ou no ambiente.
- A base de dados embutida serve para começar e continua a ser a primeira coisa a mudar. Aponte o servidor ao Postgres antes de a instalação passar a interessar a alguém.
- WOODPECKER_OPEN=true significa que qualquer conta na forja ligada pode entrar. Cómodo no primeiro dia e errado ao trigésimo.
- O agente precisa do socket do Docker porque cada passo é um contentor, o que na prática concede à pipeline root nesse host. Mantenha o host do agente aborrecido e separado.
- WOODPECKER_HOST tem de ser o URL a que a forja consegue mesmo chegar, não o interno - o webhook é criado contra ele, e um endereço privado aí produz pipelines que nunca disparam.
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
- O que é o Woodpecker CI?
Um motor de CI leve sob Apache-2.0, um fork do Drone, que corre como um servidor mais um ou mais agentes. Cada passo da pipeline é um contentor, as pipelines são um ficheiro YAML no repositório, e a autenticação passa pela sua forja. Suporta GitHub, GitLab, Gitea, Forgejo e Bitbucket, incluindo instâncias que aloje você mesmo
- Como instalo o Woodpecker CI?
O Docker Compose é o caminho documentado: um contentor woodpecker-server a expor a porta 8000 e um contentor woodpecker-agent com o socket do Docker montado, a partilhar um segredo gerado com openssl rand -hex 32, mais o id de cliente e o segredo OAuth da sua forja. O ficheiro compose oficial e os passos à volta estão nesta página
- O que é o WOODPECKER_AGENT_SECRET e como o gero?
É o segredo partilhado com que o servidor e os agentes se autenticam, e a documentação do Woodpecker nomeia openssl rand -hex 32 para o produzir. Pôr o mesmo valor em todo o lado torna-o um token de sistema; registar primeiro o agente na interface dá a esse agente um token próprio, que é o que quer assim que mais do que uma equipa consegue chegar ao host. Toda a variável sensível tem também uma forma _FILE para ler o valor de um ficheiro montado
- De que tamanho de servidor precisa o Woodpecker?
O software em si é leve - o servidor é um pequeno processo Go com base de dados embutida até o apontar ao Postgres, e o agente é um supervisor que arranca contentores. O que consome a máquina é a compilação. 2 vCPU, 4 GB e 64 GB de NVMe levam servidor e agente juntos para uma equipa pequena; passe a um host de agente dedicado assim que as pipelines começarem a fazer fila
- Porque é que o agente precisa do socket do Docker?
Porque cada passo da pipeline é um contentor que o agente arranca no daemon do host. Isso dá na prática root nessa máquina aos passos da pipeline, o que é o desenho e não uma má configuração - e é a razão para manter o agente num host que não faz mais nada, o que é barato quando uma segunda máquina custa 15 EUR por mês
- As minhas pipelines nunca disparam. O que se passa?
Nove em cada dez vezes é o WOODPECKER_HOST. Esse valor é o URL público que a forja usa quando cria o webhook, portanto um endereço interno aí produz uma instalação que parece saudável e nunca recebe um push. O outro caso frequente é WOODPECKER_OPEN=true, que não é um problema de disparo mas significa que qualquer conta na sua forja pode entrar - cómodo no primeiro dia, errado ao trigésimo
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