Woodpecker CI, sans aucun SaaS sur le chemin
Serveur et agents sur une petite machine à Prague ou Covilhã, reliés à votre propre forge - la version du CI où rien de la pipeline ne quitte une infrastructure que vous pouvez nommer.
À qui cela s'adresse
Une équipe qui héberge déjà tout le reste elle-même
La forge est à vous, le registre est à vous, la cible de déploiement est à vous - et le CI est le seul saut qui quitte encore le bâtiment, précisément celui qui détient le code source.
Une installation Drone qui a cessé d'avancer
Woodpecker est le fork qui a continué et est resté en Apache-2.0. La migration est légère ; la question est de savoir sur quoi le faire tourner.
Une petite équipe qui veut que le CI soit ennuyeux
Deux conteneurs, un fichier YAML par dépôt, aucun plan de contrôle à apprendre et aucun compteur à la minute à surveiller. Il lui faut seulement un endroit où vivre.
Ce que cette forme vous apporte
- Serveur et agent en deux conteneurs sur un hôte, assez petit pour que le CI cesse d'être un projet d'infrastructure.
- Toute forge prise en charge par Woodpecker - GitHub, GitLab, Gitea, Forgejo ou Bitbucket - y compris une que vous hébergez vous-même sur le même réseau.
- Des agents ajoutés plus tard comme hôtes séparés, tous authentifiés auprès du même serveur, quand une machine ne suffit plus.
- De l'Apache-2.0 de bout en bout, si bien que rien dans la pipeline ne dépend d'un fournisseur qui déciderait de garder une offre gratuite.
- Une IPv4 statique issue d'AS204057, pour que le webhook de la forge et la cible de déploiement aient tous deux une seule adresse à qui faire confiance.
- Du NVMe local pour l'espace de travail et le cache de couches Docker, chaud d'une pipeline à l'autre.
Dimensionné d'après ce que la pipeline fait vraiment
Woodpecker lui-même est léger : le serveur est un petit processus Go avec une base de données embarquée jusqu'à ce que vous le pointiez vers Postgres, et l'agent est un superviseur qui démarre des conteneurs. Ce qui consomme l'hôte, c'est la compilation, exactement comme avec n'importe quel autre runner - dimensionnez donc la machine d'après le job le plus lourd, et laissez de la place au disque pour le cache de couches qui rend la deuxième pipeline rapide. La taille d'entrée ci-dessous porte serveur et agent ensemble confortablement pour une petite équipe. La seule réserve honnête : un hôte mensuel fixe coûte pareil une semaine sans push, là où les minutes de CI hébergées ne coûtent rien.
Comment installer Woodpecker CI avec Docker Compose
Serveur et agent sur un hôte, reliés à GitHub dans cet exemple. Remplacez le bloc de la forge par les variables Gitea, Forgejo, GitLab ou Bitbucket si votre forge est l'une de celles-là.
-
Installer Docker et Compose
sudo apt install docker.io docker-compose-v2 sudo systemctl enable --now dockerLes deux conteneurs et chaque étape de pipeline tournent sur ce démon, c'est donc la seule dépendance dont l'hôte a besoin.
-
Enregistrer une application OAuth sur votre forge
# GitHub: Settings -> Developer settings -> OAuth Apps -> New OAuth App # Homepage URL: https://ci.example.com # Authorization callback: https://ci.example.com/authorizeWoodpecker authentifie les utilisateurs via la forge et lit les dépôts avec cette autorisation, l'identifiant client et le secret qu'elle rend sont donc ce dont le serveur a besoin. Chaque forge prise en charge possède un formulaire équivalent.
-
Générer le secret partagé de l'agent
openssl rand -hex 32Le serveur et les agents s'authentifient mutuellement avec cette chaîne, et la documentation Woodpecker nomme exactement cette commande pour la produire. Gardez-la hors du fichier compose - mettez-la dans un fichier .env à côté.
-
Écrire le fichier 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:C'est l'exemple officiel. WOODPECKER_HOST est l'URL publique que joignent utilisateurs et webhooks, le port 8000 est l'interface web et le 9000 le port gRPC sur lequel les agents se connectent. WOODPECKER_OPEN=true laisse entrer quiconque possède un compte sur la forge - désactivez-le une fois votre équipe enregistrée.
-
Le démarrer
docker compose up -d docker compose logs -f woodpecker-agentL'agent se connecte au serveur avec le secret partagé et s'enregistre lui-même au premier contact. S'il boucle sur une erreur d'authentification, les deux secrets ne concordent pas - le plus souvent parce que le fichier .env n'a pas été pris en compte.
-
Ajouter une pipeline
when: - event: push steps: - name: smoke image: alpine:latest commands: - cat /etc/os-release - echo "built on $CI_MACHINE"Committez ceci en tant que .woodpecker.yaml, activez le dépôt dans l'interface web pour que le webhook soit créé, et poussez. Chaque étape est un conteneur, et c'est pourquoi l'agent a besoin du socket Docker.
Vérifié sur la documentation officielle le 2026-08-15 — lire la source
Ce que nous ne sommes pas
- Nous ne sommes pas le projet Woodpecker. Woodpecker CI est un projet Apache-2.0 indépendant et rien ici n'est approuvé par lui. Nous vendons la machine sur laquelle il tourne.
- Nous n'hébergeons pas votre forge sur cette page. Gitea, Forgejo ou un GitLab autogéré à côté est un second serveur sans difficulté, mais c'est une autre taille et un autre devis.
- Nous n'écrivons pas vos pipelines. Le YAML est à vous ; l'hôte, le réseau et l'adresse sont à nous.
- Woodpecker n'est pas géré pour vous par défaut. Vous faites tourner les deux conteneurs, ou vous ajoutez notre service d'administration et nous les gardons à jour et sauvegardés.
- Monter le socket Docker dans l'agent donne aux étapes de la pipeline énormément de pouvoir sur l'hôte. C'est ainsi que cette conception fonctionne, et c'est une raison de garder l'agent sur une machine qui ne fait rien d'autre.
Les parties que les équipes découvrent tard
- WOODPECKER_AGENT_SECRET a deux modes. La même valeur sur le serveur et sur tous les agents est un jeton système ; un jeton par agent s'obtient en enregistrant d'abord l'agent dans l'interface, ce que vous voulez dès que plus d'une équipe peut atteindre l'hôte.
- Toute variable sensible possède aussi une forme _FILE, si bien que le secret peut être lu depuis un fichier monté au lieu de figurer dans le fichier compose ou dans l'environnement.
- La base de données embarquée convient pour commencer et reste la première chose à déplacer. Pointez le serveur vers Postgres avant que l'installation n'ait d'importance pour quelqu'un.
- WOODPECKER_OPEN=true signifie que n'importe quel compte de la forge connectée peut se connecter. Pratique le premier jour et faux le trentième.
- L'agent a besoin du socket Docker parce que chaque étape est un conteneur, ce qui accorde en pratique le root de cet hôte à la pipeline. Gardez l'hôte de l'agent ennuyeux et séparé.
- WOODPECKER_HOST doit être l'URL que la forge peut réellement joindre, pas l'interne - le webhook est créé contre elle, et une adresse privée à cet endroit produit des pipelines qui ne se déclenchent jamais.
Minutes de CI hébergées face à un runner à vous
| Minutes de CI hébergées par le fournisseur | Un runner chez DCXV | |
|---|---|---|
| Ce que vous payez | Chaque minute de chaque job, aussi longtemps que le projet existe | Un hôte mensuel fixe, quoi que fasse la pipeline ce mois-là |
| Une compilation qui ralentit | Coûte plus cher chaque mois où elle reste lente | Ne coûte rien de plus - la machine est déjà payée |
| Cache de couches Docker | Froid à chaque job sauf si vous le téléversez et le retéléchargez vous-même | Chaud sur du NVMe local, entre les jobs et entre les journées |
| Parallélisme | Un palier d'abonnement que l'on augmente | Un nombre que vous posez dans votre propre fichier de configuration |
| Où atterrit le checkout | Une flotte partagée, souvent dans une région que vous ne pouvez pas fixer | Une machine à Prague ou Covilhã, sous contrat chypriote |
| Adresse sortante | Une vaste plage partagée que rien ne peut autoriser | Une IPv4 statique issue d'AS204057, la vôtre à autoriser |
| Ce que la machine peut contenir | Ce que l'image du runner apporte par hasard | Toute chaîne d'outils, licence ou jeu de fixtures installé une fois |
Comment cela démarre sur votre hôte
Dites-nous ce que fait la pipeline
Le job le plus lourd que vous exécutez aujourd'hui, combien vous en voulez en parallèle, et s'il construit des images de conteneur. Cela suffit pour dimensionner un hôte sans deviner.
Nous vous remettons la machine
Prague ou Covilhã, accès root et une IPv4 statique, en moins de dix minutes. Apportez votre propre image si le runner y est déjà intégré.
Suivez le pas à pas de cette page
C'est la séquence de l'éditeur, tirée de sa documentation actuelle plutôt que d'un article de blog, et elle prend quelques minutes sur un hôte propre.
Faites un snapshot, puis ajoutez le second
Prenez un snapshot dès que la première pipeline est verte, pour que la machine suivante soit une restauration et non une reconstruction. Un pool grandit en ajoutant des hôtes, pas en en rendant un énorme.
Pourquoi nous choisir
- Sites certifiés Tier III, SLA du site de 99,982 %
- Réseau propre, AS204057, IPv4 et IPv6
- Support 24/7/365 avec environ 10 minutes de réponse moyenne
- Société chypriote, juridiction de l'UE, conforme au RGPD depuis 2007
FAQ
- Qu'est-ce que Woodpecker CI ?
Un moteur de CI léger sous Apache-2.0, forké de Drone, qui fonctionne avec un serveur et un ou plusieurs agents. Chaque étape de pipeline est un conteneur, les pipelines sont un fichier YAML dans le dépôt, et l'authentification passe par votre forge. Il prend en charge GitHub, GitLab, Gitea, Forgejo et Bitbucket, y compris des instances que vous hébergez vous-même
- Comment installer Woodpecker CI ?
Docker Compose est la voie documentée : un conteneur woodpecker-server exposant le port 8000 et un conteneur woodpecker-agent avec le socket Docker monté, partageant un secret généré par openssl rand -hex 32, plus l'identifiant client et le secret OAuth de votre forge. Le fichier compose officiel et les étapes qui l'entourent sont sur cette page
- Qu'est-ce que WOODPECKER_AGENT_SECRET et comment le générer ?
C'est le secret partagé avec lequel le serveur et les agents s'authentifient, et la documentation Woodpecker nomme openssl rand -hex 32 pour le produire. Mettre la même valeur partout en fait un jeton système ; enregistrer d'abord l'agent dans l'interface lui donne à la place son propre jeton, ce que vous voulez dès que plus d'une équipe peut atteindre l'hôte. Toute variable sensible possède aussi une forme _FILE pour lire la valeur depuis un fichier monté
- Quelle taille de serveur faut-il pour Woodpecker ?
Le logiciel lui-même est léger - le serveur est un petit processus Go avec une base de données embarquée jusqu'à ce que vous le pointiez vers Postgres, et l'agent est un superviseur qui démarre des conteneurs. Ce qui consomme la machine, c'est la compilation. 2 vCPU, 4 Go et 64 Go de NVMe portent serveur et agent ensemble pour une petite équipe ; passez à un hôte agent dédié dès que les pipelines commencent à faire la queue
- Pourquoi l'agent a-t-il besoin du socket Docker ?
Parce que chaque étape de pipeline est un conteneur que l'agent démarre sur le démon de l'hôte. Cela donne en pratique le root de cette machine aux étapes de la pipeline, ce qui est la conception et non une mauvaise configuration - et c'est la raison de garder l'agent sur un hôte qui ne fait rien d'autre, ce qui coûte peu quand une seconde machine revient à 15 EUR par mois
- Mes pipelines ne se déclenchent jamais. Quel est le problème ?
Neuf fois sur dix, c'est WOODPECKER_HOST. Cette valeur est l'URL publique qu'utilise la forge quand elle crée le webhook, une adresse interne à cet endroit produit donc une installation qui a l'air saine et ne reçoit jamais de push. L'autre cas fréquent est WOODPECKER_OPEN=true, qui n'est pas un problème de déclenchement mais signifie que tout compte sur votre forge peut se connecter - pratique le premier jour, faux le trentième
Si vous avez besoin d'aide ou avez des questions supplémentaires, veuillez contacter les managers ou écrire à l'équipe de support à support@dcxv.com
Prêt à commencer ?
Facturation mensuelle, sans frais de mise en service, sans engagement