Woodpecker CI, senza alcun SaaS di mezzo

Server e agent su una piccola macchina a Praga o Covilhã, collegati alla vostra forge - la versione della CI in cui nulla della pipeline esce da un'infrastruttura che potete nominare.

Certificato Tier III ISO 9001 ISO/IEC 27001 ISO 14001 Conforme al GDPR

Per chi è

Un team che ospita già in casa tutto il resto

La forge è vostra, il registry è vostro, la destinazione di deploy è vostra - e la CI è l'unico salto che esce ancora dall'edificio, proprio il salto che tiene il codice.

Un'installazione Drone che si è fermata

Woodpecker è il fork che è andato avanti ed è rimasto Apache-2.0. La migrazione è piccola; la domanda è su che cosa farlo girare.

Un team piccolo che vuole una CI noiosa

Due container, un file YAML per repository, nessun piano di controllo da imparare e nessun contatore al minuto da sorvegliare. Gli serve soltanto un posto dove stare.

Che cosa vi dà questa forma

  • Server e agent come due container su un host, abbastanza piccolo perché la CI smetta di essere un progetto di infrastruttura.
  • Qualsiasi forge supportata da Woodpecker - GitHub, GitLab, Gitea, Forgejo o Bitbucket - compresa una che ospitate voi sulla stessa rete.
  • Agent aggiunti più avanti come host separati, tutti autenticati sullo stesso server, quando una macchina non basta più.
  • Apache-2.0 dall'inizio alla fine, così nulla nella pipeline dipende dal fatto che un fornitore decida di mantenere un piano gratuito.
  • Un IPv4 statico da AS204057, così il webhook della forge e la destinazione di deploy hanno entrambi un solo indirizzo di cui fidarsi.
  • NVMe locale per lo spazio di lavoro e la cache dei layer Docker, caldo tra una pipeline e l'altra.

Dimensionato su quello che la pipeline fa davvero

Woodpecker in sé è leggero: il server è un piccolo processo Go con database incorporato finché non lo puntate a Postgres, e l'agent è un supervisore che avvia container. Quello che consuma l'host è la build, esattamente come con qualsiasi altro runner - quindi dimensionate la macchina sul job più pesante e date spazio al disco per la cache dei layer che rende veloce la seconda pipeline. La taglia d'ingresso qui sotto regge server e agent insieme con comodità per un team piccolo. L'unica avvertenza onesta: un host mensile fisso costa lo stesso in una settimana senza push, dove i minuti di CI ospitati non costano nulla.

Un primo runner
15.00
al mese

Ordina Ora
server e un agent insieme
2 vCPU
4 GB RAM
64 GB NVMe
1 IPv4 statico
1 backup settimanale incluso
Un runner di team
19.96
al mese

Ordina Ora
server più un paio di workflow in parallelo
4 vCPU
8 GB RAM
120 GB NVMe
1 IPv4 statico
1 backup settimanale incluso
Un pool carico
39.90
al mese

Ordina Ora
un host agent dedicato accanto al server
8 vCPU
16 GB RAM
240 GB NVMe
1 IPv4 statico
1 backup settimanale incluso

Come installare Woodpecker CI con Docker Compose

Server e agent su un host, collegati a GitHub in questo esempio. Sostituite il blocco della forge con le variabili di Gitea, Forgejo, GitLab o Bitbucket se la vostra forge è una di quelle.

  1. Installare Docker e Compose

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

    Entrambi i container e ogni passo della pipeline girano su questo demone, quindi è l'unica dipendenza di cui l'host ha bisogno.

  2. Registrare un'applicazione OAuth sulla vostra forge

    # GitHub: Settings -> Developer settings -> OAuth Apps -> New OAuth App
    # Homepage URL:     https://ci.example.com
    # Authorization callback: https://ci.example.com/authorize

    Woodpecker autentica gli utenti attraverso la forge e legge i repository con quel permesso, quindi l'id client e il segreto che restituisce sono ciò che serve al server. Ogni forge supportata ha un modulo equivalente.

  3. Generare il segreto condiviso dell'agent

    openssl rand -hex 32

    Server e agent si autenticano a vicenda con questa stringa, e la documentazione Woodpecker indica esattamente questo comando per produrla. Tenetela fuori dal file compose - mettetela in un file .env accanto.

  4. Scrivere il file 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:

    Questo è l'esempio ufficiale. WOODPECKER_HOST è l'URL pubblico che raggiungono utenti e webhook, la porta 8000 è l'interfaccia web e la 9000 è la porta gRPC su cui si collegano gli agent. WOODPECKER_OPEN=true lascia entrare chiunque abbia un account sulla forge - disattivatelo appena il vostro team è registrato.

  5. Avviarlo

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

    L'agent si collega al server con il segreto condiviso e si registra da solo al primo contatto. Se entra in ciclo con un errore di autenticazione, i due segreti non coincidono - quasi sempre perché il file .env non è stato letto.

  6. Aggiungere una pipeline

    when:
      - event: push
    
    steps:
      - name: smoke
        image: alpine:latest
        commands:
          - cat /etc/os-release
          - echo "built on $CI_MACHINE"

    Fate il commit come .woodpecker.yaml, abilitate il repository nell'interfaccia web perché venga creato il webhook, e fate push. Ogni passo è un container, ed è per questo che all'agent serve il socket di Docker.

Verificato sulla documentazione ufficiale il 2026-08-15 — leggi la fonte

Cosa non siamo

  • Non siamo il progetto Woodpecker. Woodpecker CI è un progetto Apache-2.0 indipendente e nulla qui è approvato da esso. Vendiamo la macchina su cui gira.
  • Su questa pagina non ospitiamo la vostra forge. Gitea, Forgejo o un GitLab autogestito accanto è un secondo server senza complicazioni, ma è un'altra taglia e un altro preventivo.
  • Non scriviamo le vostre pipeline. Lo YAML è vostro; l'host, la rete e l'indirizzo sono nostri.
  • Woodpecker non viene gestito per voi per impostazione predefinita. I due container li fate girare voi, oppure aggiungete il nostro servizio di amministrazione e li teniamo aggiornati e salvati.
  • Montare il socket di Docker dentro l'agent dà ai passi della pipeline moltissimo potere sull'host. È così che questo disegno funziona, ed è una ragione per tenere l'agent su una macchina che non fa nient'altro.

Le parti che i team scoprono in ritardo

  • WOODPECKER_AGENT_SECRET ha due modalità. Lo stesso valore sul server e su tutti gli agent è un token di sistema; un token per agent nasce registrando prima l'agent nell'interfaccia, che è quello che volete appena più di un team può raggiungere l'host.
  • Ogni variabile sensibile ha anche una forma _FILE, così il segreto può essere letto da un file montato invece di stare nel file compose o nell'ambiente.
  • Il database incorporato va bene per iniziare ed è comunque la prima cosa da spostare. Puntate il server a Postgres prima che l'installazione cominci a contare per qualcuno.
  • WOODPECKER_OPEN=true significa che qualsiasi account sulla forge collegata può entrare. Comodo il primo giorno e sbagliato il trentesimo.
  • All'agent serve il socket di Docker perché ogni passo è un container, il che di fatto concede alla pipeline il root su quell'host. Tenete l'host dell'agent noioso e separato.
  • WOODPECKER_HOST deve essere l'URL che la forge può davvero raggiungere, non quello interno - il webhook viene creato su di esso, e un indirizzo privato lì produce pipeline che non scattano mai.

Minuti di CI ospitati contro un runner vostro

Minuti di CI ospitati dal fornitoreUn runner su DCXV
Che cosa pagateOgni minuto di ogni job, finché il progetto esisteUn host mensile fisso, qualunque cosa faccia la pipeline quel mese
Una build che rallentaCosta di più ogni mese in cui resta lentaNon costa nulla in più - la macchina è già pagata
Cache dei layer DockerFredda a ogni job, se non la caricate e la riscaricate voi stessiCalda su NVMe locale, tra i job e tra i giorni
ParallelizzazioneUno scalino di piano che si aumentaUn numero che impostate nel vostro file di configurazione
Dove atterra il checkoutUna flotta condivisa, spesso in una regione che non potete fissareUna macchina a Praga o Covilhã, con contratto cipriota
Indirizzo in uscitaUn vasto intervallo condiviso che nulla può autorizzareUn IPv4 statico da AS204057, vostro da autorizzare
Che cosa può contenere la macchinaQuello che l'immagine del runner porta per casoQualsiasi toolchain, licenza o set di fixture installato una volta sola

Come si mette in moto sul vostro host

1

Diteci che cosa fa la pipeline

Il job più pesante che eseguite oggi, quanti ne volete in parallelo e se costruisce immagini di container. Basta questo per dimensionare un host senza tirare a indovinare.

2

Vi consegniamo la macchina

Praga o Covilhã, accesso root e un IPv4 statico, in meno di dieci minuti. Portate la vostra immagine se il runner è già dentro.

3

Seguite la procedura di questa pagina

È la sequenza del produttore, presa dalla sua documentazione attuale e non da un post di blog, e su un host pulito richiede pochi minuti.

4

Fate uno snapshot, poi aggiungete il secondo

Fate uno snapshot appena la prima pipeline è verde, così la macchina successiva è un ripristino e non una ricostruzione. Un pool cresce aggiungendo host, non rendendone uno enorme.

Perché sceglierci

  • Strutture certificate Tier III, SLA della struttura 99,982 %
  • Rete propria, AS204057, IPv4 e IPv6
  • Supporto 24/7/365 con circa 10 minuti di risposta media
  • Società cipriota, giurisdizione UE, conforme al GDPR dal 2007

FAQ

- Che cos'è Woodpecker CI?

Un motore di CI leggero sotto Apache-2.0, nato come fork di Drone, che gira come un server più uno o più agent. Ogni passo della pipeline è un container, le pipeline sono un file YAML nel repository, e l'accesso passa dalla vostra forge. Supporta GitHub, GitLab, Gitea, Forgejo e Bitbucket, comprese istanze che ospitate voi

- Come installo Woodpecker CI?

Docker Compose è la via documentata: un container woodpecker-server che espone la porta 8000 e un container woodpecker-agent con il socket di Docker montato, che condividono un segreto generato con openssl rand -hex 32, più l'id client e il segreto OAuth della vostra forge. Il file compose ufficiale e i passi attorno sono su questa pagina

- Che cos'è WOODPECKER_AGENT_SECRET e come lo genero?

È il segreto condiviso con cui server e agent si autenticano, e la documentazione Woodpecker indica openssl rand -hex 32 per produrlo. Mettere lo stesso valore ovunque ne fa un token di sistema; registrare prima l'agent nell'interfaccia dà a quell'agent un token proprio, che è quello che volete appena più di un team può raggiungere l'host. Ogni variabile sensibile ha anche una forma _FILE per leggere il valore da un file montato

- Che dimensione di server serve a Woodpecker?

Il software in sé è leggero - il server è un piccolo processo Go con database incorporato finché non lo puntate a Postgres, e l'agent è un supervisore che avvia container. Quello che consuma la macchina è la build. 2 vCPU, 4 GB e 64 GB di NVMe reggono server e agent insieme per un team piccolo; passate a un host agent dedicato appena le pipeline cominciano a fare coda

- Perché all'agent serve il socket di Docker?

Perché ogni passo della pipeline è un container che l'agent avvia sul demone dell'host. Questo dà di fatto ai passi della pipeline il root su quella macchina, che è il disegno e non un errore di configurazione - ed è la ragione per tenere l'agent su un host che non fa nient'altro, cosa poco costosa quando una seconda macchina costa 15 EUR al mese

- Le mie pipeline non scattano mai. Che cosa non va?

Nove volte su dieci è WOODPECKER_HOST. Quel valore è l'URL pubblico che la forge usa quando crea il webhook, quindi un indirizzo interno lì produce un'installazione che sembra sana e non riceve mai un push. L'altro caso frequente è WOODPECKER_OPEN=true, che non è un problema di attivazione ma significa che qualsiasi account sulla vostra forge può entrare - comodo il primo giorno, sbagliato il trentesimo

Se hai bisogno di assistenza o hai domande aggiuntive, contatta i manager o scrivi al team di supporto a support@dcxv.com

Pronto per iniziare?

Fatturazione mensile, nessun costo di attivazione, nessun vincolo

Server cloud da 15 €/mese