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
Domande frequenti
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