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.

Certificado Tier III ISO 9001 ISO/IEC 27001 ISO 14001 Conforme com o RGPD

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.

Um primeiro runner
15.00
por mês

Encomendar agora
servidor e um agente juntos
2 vCPU
4 GB RAM
64 GB NVMe
1 IPv4 estático
1 cópia semanal incluída
Um runner de equipa
19.96
por mês

Encomendar agora
servidor mais alguns workflows em paralelo
4 vCPU
8 GB RAM
120 GB NVMe
1 IPv4 estático
1 cópia semanal incluída
Um pool com carga
39.90
por mês

Encomendar agora
um host de agente dedicado ao lado do servidor
8 vCPU
16 GB RAM
240 GB NVMe
1 IPv4 estático
1 cópia semanal incluída

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.

  1. Instalar o Docker e o Compose

    sudo apt install docker.io docker-compose-v2
    sudo systemctl enable --now docker

    Ambos os contentores e cada passo da pipeline correm neste daemon, portanto é a única dependência de que o host precisa.

  2. 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/authorize

    O 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.

  3. Gerar o segredo partilhado do agente

    openssl rand -hex 32

    O 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.

  4. 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.

  5. Arrancar

    docker compose up -d
    docker compose logs -f woodpecker-agent

    O 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.

  6. 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 fornecedorUm runner na DCXV
O que pagaCada minuto de cada job, enquanto o projeto existirUm host mensal fixo, faça a pipeline o que fizer nesse mês
Uma compilação que fica mais lentaCusta mais em cada mês que continue lentaNão custa mais nada - a máquina já está paga
Cache de camadas DockerFria em cada job a não ser que a envie e a descarregue você mesmoQuente em NVMe local, entre jobs e entre dias
ConcorrênciaUm escalão de plano que se sobeUm número que define no seu próprio ficheiro de configuração
Onde aterra o checkoutUma frota partilhada, muitas vezes numa região que não consegue fixarUma máquina em Praga ou na Covilhã, sob contrato cipriota
Endereço de saídaUma gama partilhada enorme que nada consegue autorizarUm IPv4 estático do AS204057, seu para autorizar
O que a máquina pode conterO que a imagem do runner por acaso tragaQualquer toolchain, licença ou conjunto de fixtures que instale uma vez

Como isto arranca no seu host

1

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.

2

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.

3

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.

4

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

Servidores na nuvem desde 15 €/mês