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.

Certifié Tier III ISO 9001 ISO/IEC 27001 ISO 14001 Conforme au RGPD

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

Un premier runner
15.00
par mois

Commander maintenant
serveur et un agent ensemble
2 vCPU
4 GB RAM
64 GB NVMe
1 IPv4 statique
1 sauvegarde hebdomadaire incluse
Un runner d'équipe
19.96
par mois

Commander maintenant
serveur plus deux ou trois workflows en parallèle
4 vCPU
8 GB RAM
120 GB NVMe
1 IPv4 statique
1 sauvegarde hebdomadaire incluse
Un pool chargé
39.90
par mois

Commander maintenant
un hôte agent dédié à côté du serveur
8 vCPU
16 GB RAM
240 GB NVMe
1 IPv4 statique
1 sauvegarde hebdomadaire incluse

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

  1. Installer Docker et Compose

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

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

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

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

  3. Générer le secret partagé de l'agent

    openssl rand -hex 32

    Le 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é.

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

  5. Le démarrer

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

    L'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.

  6. 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 fournisseurUn runner chez DCXV
Ce que vous payezChaque minute de chaque job, aussi longtemps que le projet existeUn hôte mensuel fixe, quoi que fasse la pipeline ce mois-là
Une compilation qui ralentitCoûte plus cher chaque mois où elle reste lenteNe coûte rien de plus - la machine est déjà payée
Cache de couches DockerFroid à chaque job sauf si vous le téléversez et le retéléchargez vous-mêmeChaud sur du NVMe local, entre les jobs et entre les journées
ParallélismeUn palier d'abonnement que l'on augmenteUn nombre que vous posez dans votre propre fichier de configuration
Où atterrit le checkoutUne flotte partagée, souvent dans une région que vous ne pouvez pas fixerUne machine à Prague ou Covilhã, sous contrat chypriote
Adresse sortanteUne vaste plage partagée que rien ne peut autoriserUne IPv4 statique issue d'AS204057, la vôtre à autoriser
Ce que la machine peut contenirCe que l'image du runner apporte par hasardToute chaîne d'outils, licence ou jeu de fixtures installé une fois

Comment cela démarre sur votre hôte

1

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.

2

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

3

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.

4

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

Serveurs cloud dès 15 €/mois