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.
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.
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.
-
Installare Docker e Compose
sudo apt install docker.io docker-compose-v2 sudo systemctl enable --now dockerEntrambi i container e ogni passo della pipeline girano su questo demone, quindi è l'unica dipendenza di cui l'host ha bisogno.
-
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/authorizeWoodpecker 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.
-
Generare il segreto condiviso dell'agent
openssl rand -hex 32Server 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.
-
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.
-
Avviarlo
docker compose up -d docker compose logs -f woodpecker-agentL'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.
-
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 fornitore | Un runner su DCXV | |
|---|---|---|
| Che cosa pagate | Ogni minuto di ogni job, finché il progetto esiste | Un host mensile fisso, qualunque cosa faccia la pipeline quel mese |
| Una build che rallenta | Costa di più ogni mese in cui resta lenta | Non costa nulla in più - la macchina è già pagata |
| Cache dei layer Docker | Fredda a ogni job, se non la caricate e la riscaricate voi stessi | Calda su NVMe locale, tra i job e tra i giorni |
| Parallelizzazione | Uno scalino di piano che si aumenta | Un numero che impostate nel vostro file di configurazione |
| Dove atterra il checkout | Una flotta condivisa, spesso in una regione che non potete fissare | Una macchina a Praga o Covilhã, con contratto cipriota |
| Indirizzo in uscita | Un vasto intervallo condiviso che nulla può autorizzare | Un IPv4 statico da AS204057, vostro da autorizzare |
| Che cosa può contenere la macchina | Quello che l'immagine del runner porta per caso | Qualsiasi toolchain, licenza o set di fixture installato una volta sola |
Come si mette in moto sul vostro host
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.
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.
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.
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