Woodpecker CI : le fork communautaire de Drone

Vous lancez Drone en self-hosting depuis des années, tranquille, et un matin vous tombez sur la licence. Plus Apache 2.0. Polyform Small Business. Au-dessus d'un certain usage en production, il faut payer Harness. Ce scénario, des équipes ops l'ont vécu pour de vrai. Et c'est exactement ce qui a donné naissance à Woodpecker.

Drone démarre comme un moteur de CI/CD open source sous Apache 2.0, pensé conteneurs dès le départ. Léger, propre, chaque step dans son conteneur. Puis la trajectoire bascule. En août 2020, Harness rachète Drone. L'édition open source reste sous Apache 2.0, mais l'édition Enterprise, celle qui est désormais poussée et maintenue, passe sous licence Polyform Small Business : un modèle source-available qui n'a d'open source que l'apparence, le code est lisible, mais l'usage commercial au-delà d'un certain seuil de revenus exige une licence payante.

Le glissement n'a rien d'anodin pour un opérateur. Une CI/CD, c'est le cœur de la chaîne de livraison. Bâtir sa prod sur un outil dont la gouvernance et le modèle de licence peuvent se durcir du jour au lendemain, c'est un risque qu'on ne contrôle pas. Quand la licence change après coup, on hérite d'une dette qu'on n'a pas signée.

Woodpecker naît de ce refus. Le fork repart de la dernière version de Drone encore sous Apache 2.0 (la 0.8, juste avant le passage en licence restrictive) et garde cette licence. Le projet est porté par une communauté de développeurs, sans éditeur unique derrière qui décide seul du sort du code. La philosophie de Drone reste : un serveur, des agents, des pipelines déclaratifs, tout en conteneurs. La gouvernance, elle, change de nature.

Ce mouvement n'a rien d'isolé. Quand un éditeur referme un projet libre, la communauté forke. Redis vire vers une licence non-OSI, Valkey démarre sous l'aile de la Linux Foundation. HashiCorp passe Terraform en BSL, OpenTofu prend le relais. Même histoire avec Vault et OpenBao. Woodpecker s'inscrit dans cette série : la réponse libre à une fermeture commerciale. La leçon ops est sèche. Une dépendance critique sous le contrôle exclusif d'un éditeur reste un risque de licence, indépendamment de la qualité du produit.

L'architecture tient en deux blocs. Un serveur central, des agents qui exécutent.

Le serveur orchestre. Il expose une API REST et une interface web, dialogue avec la forge Git, gère l'authentification, la file des pipelines et les secrets. Côté empreinte, il tourne autour de 100 Mo de RAM au repos. L'agent, lui, fait le travail sale : il se connecte au serveur en gRPC, récupère les tâches dans la file, et lance chaque step. Au repos, un agent consomme une trentaine de Mo. On parle d'un ordre de grandeur que GitLab ne touchera jamais avec son usine.

Chaque step d'un pipeline s'exécute dans son propre conteneur. C'est le principe hérité de Drone, et c'est ce qui rend la chose propre : isolation entre les étapes, image dédiée par job, reproductibilité d'un run à l'autre. Vous voulez Node 22 pour les tests et une image Docker minimale pour le build ? Deux images, deux conteneurs, zéro pollution croisée.

Le découpage serveur/agents donne un avantage concret en exploitation : la scalabilité horizontale des agents. Plusieurs agents coexistent, chacun avec son backend, ses limites de jobs concurrents, sa config. La charge monte, on ajoute des agents. Sur une infra qu'on opère, ça veut dire qu'on dimensionne la capacité de build comme on dimensionne n'importe quel pool de workers, sans toucher au serveur.

L'agent exécute les workflows via un backend, et c'est là que Woodpecker s'adapte au terrain.

Le backend docker est le défaut. Chaque step devient un conteneur Docker sur l'hôte de l'agent. C'est le mode le plus simple à opérer, parfait pour une VM ou un petit cluster d'agents derrière une forge légère.

Le backend kubernetes exécute chaque step dans un Pod autonome. Pour transférer les fichiers entre steps (le code cloné, les artefacts intermédiaires), Woodpecker crée un PVC temporaire vivant le temps du pipeline, puis le détruit. On délègue le scheduling à Kubernetes, on récupère l'isolation des Pods et la capacité du cluster. C'est le mode des équipes déjà sur K8s qui ne veulent pas un runner de plus à gérer à côté.

Le backend local exécute les commandes directement sur la machine de l'agent, sans conteneur. À réserver aux cas où la conteneurisation gêne, en sachant qu'on perd l'isolation qui fait tout l'intérêt du modèle. À manier avec prudence.

Le pipeline se déclare en YAML, dans un fichier .woodpecker.yml versionné avec le code. La structure reste lisible : des steps, une image par step, des commandes. Pas de DSL ésotérique à apprendre.

steps:
  test:
    image: node:22
    commands:
      - npm ci
      - npm test
  build:
    image: plugins/docker
    settings:
      repo: example/app
      tags: ${CI_COMMIT_SHA}

Côté forge, Woodpecker se branche en OAuth2 sur Gitea, Forgejo, GitHub, GitLab et Bitbucket. L'abstraction interne repose sur une interface forge.Forge que chaque driver implémente, ce qui garde le moteur agnostique du fournisseur Git. Détail qui compte : Forgejo et Gitea ont chacun leur driver, parce que les deux SDK ont divergé depuis le fork. Si vous hésitez encore entre les deux moteurs, on a creusé le sujet dans notre analyse du fork Forgejo face à Gitea.

Les plugins sont des conteneurs Docker, comme les steps. Build d'image, notifications Slack, upload d'artefacts vers S3 : tout passe par des images dédiées, et l'écosystème reste ouvert puisque n'importe quel conteneur peut devenir un plugin. Les secrets se déclarent à trois portées : par dépôt, par organisation, ou globaux côté admin. Ils sont chiffrés au repos et injectés uniquement dans les pipelines explicitement autorisés, avec des backends externes type Vault possibles.

Trois outils, trois philosophies. Le tableau cadre la décision.

Drone reste techniquement proche, c'est le même socle. Mais la question n'est pas technique, elle est de gouvernance : on ne rebâtit pas sa CI sur un outil dont la licence peut se reverrouiller. GitLab CI joue dans une autre catégorie : une plateforme complète, registry, issues, CI, le tout intégré. Cohérent quand on vit déjà dans GitLab, surdimensionné quand on veut juste un moteur de pipelines derrière une forge légère. On a détaillé ce monde dans notre guide GitLab CI sur Kubernetes.

Le piège classique, c'est de prendre l'usine par réflexe et de traîner ensuite des gigas de RAM pour faire tourner trois steps. Woodpecker tranche dans l'autre sens : le strict nécessaire pour exécuter des conteneurs, rien de plus.

Pour une petite ou moyenne équipe en self-hosting derrière une forge légère (Gitea ou Forgejo en tête), Woodpecker est le bon choix. Léger, déclaratif, sous une licence qui ne se retournera pas contre vous, et opérationnellement simple : un serveur, des agents qu'on multiplie selon la charge. Si vous montez justement une forge auto-hébergée, nos guides de déploiement de Gitea et de runners GitHub auto-hébergés complètent le tableau.

On ne le recommande pas si vous êtes déjà investi à fond dans l'écosystème GitLab : dans ce cas, GitLab CI vous évite de coller un second outil. Mais pour tout le reste, le combo forge légère plus Woodpecker reste le plus propre à opérer.

Monter une chaîne CI/CD auto-hébergée, c'est facile à démarrer et pénible à tenir dans la durée : agents qui saturent, runners qui dérivent, secrets éparpillés. Quand on reprend une CI rafistolée, on remet à plat la capacité des agents, la rotation des secrets et la supervision des pipelines. C'est ce qu'on fait sur les infras qu'on opère. Si votre CI tient avec des bouts de ficelle, on peut auditer la chaîne et la mettre au niveau.

• About | Woodpecker CI : historique du fork, origine Apache 2.0 et gouvernance communautaire.
• System Architecture | Woodpecker CI (DeepWiki) : décomposition serveur/agents, gRPC, empreinte mémoire.
• Kubernetes backend | Woodpecker CI : exécution des steps en Pods et PVC temporaire.
• Supported Forges | Woodpecker CI (DeepWiki) : forges supportées et interface forge.Forge.
• Woodpecker CI plugins : écosystème de plugins conteneurisés.