[{"data":1,"prerenderedAt":170},["ShallowReactive",2],{"seo-verification":3,"blog-woodpecker-ci-pipeline-vps-forgejo-ma-fr":6,"promo-bar-likely":169},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-woodpecker-ci-pipeline-vps-forgejo-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":26,"featuredImage":28,"bgImage":29,"posterImage":30,"relatedSolution":28,"intro":31,"sections":32,"ctaTitle":103,"ctaBody":104,"ctaButton":105,"ctaUrl":106,"relatedPosts":107},212,"woodpecker-ci-pipeline-vps-forgejo",{"fr":10,"en":12,"ar":13,"es":14},"woodpecker-ci-and-forgejo-cicd-pipeline-on-a-vps","woodpecker-ci-وforgejo-خط-أنابيب-cicd-على-خادم-vps","woodpecker-ci-forgejo-pipeline-cicd-vps","Woodpecker CI et Forgejo : pipeline CI\u002FCD sur VPS","Déployez Woodpecker CI v3 avec Forgejo sur votre VPS : installation Docker Compose, pipeline YAML, secrets, runners multi-arch et dépannage OAuth.",12,2,false,"2026-08-02T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":18,"name":23,"slug":24,"color":25,"icon":24},"Automatisation","automatisation","bg-brand-action\u002F10 text-brand-action",[27],{"id":18,"name":23,"slug":24,"color":25,"icon":24},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fwoodpecker-ci-pipeline-vps-forgejo-poster.svg","Woodpecker CI est un moteur de pipeline open source, fork communautaire de Drone CI sous licence Apache 2.0, conçu pour s'associer nativement à Forgejo. En version 3.20 (octobre 2026), il fait tourner chaque étape dans un conteneur Docker isolé ; au repos, le serveur occupe environ 100 Mo de RAM et l'agent environ 30 Mo. Sur un VPS, les builds s'exécutent au plus près du dépôt git : pas de file d'attente cloud, pas de quota de minutes à surveiller, aucun secret d'intégration ne quitte votre réseau.",[33,37,48,51,54,82,85,88,91,94,97,100],{"type":34,"title":35,"body":36},"h2","Pourquoi quitter les CI cloud pour un pipeline sur votre VPS","Les offres CI cloud facturent à la minute de build et imposent des files d'attente partagées dont le temps d'attente augmente avec le volume. Dès que les dépôts grossissent ou que les tests se multiplient, la facture dépasse rapidement le coût d'un VPS dédié. Héberger Forgejo et Woodpecker CI sur le même serveur supprime cette latence réseau : le runner lit le code en local, sans transit par une infrastructure tierce. Vous gardez aussi la maîtrise du cycle de mise à jour — aucun changement de tarification ou de règles de rétention de logs ne s'applique sans votre accord. Pour les équipes soumises à des contraintes réglementaires ou de confidentialité, c'est un avantage décisif : les secrets d'intégration (clés SSH de déploiement, tokens d'accès registre) ne franchissent jamais le périmètre de votre réseau. Enfin, la licence Apache 2.0 garantit que le code source reste auditable et que le projet ne peut basculer derrière une offre commerciale exclusive.",{"type":38,"title":39,"items":40},"ul","Ce que Woodpecker CI apporte sur VPS",[41,42,43,44,45,46,47],"**Isolation Docker par étape** — chaque step tourne dans son propre conteneur, sans état partagé entre les jobs ; un step qui plante ne corrompt pas les suivants.","**Empreinte mémoire réduite** — au repos, le serveur occupe environ 100 Mo de RAM et l'agent environ 30 Mo, ce qui laisse la majeure partie des ressources aux builds eux-mêmes.","**Configuration YAML minimaliste** — un fichier `.woodpecker.yaml` à la racine du dépôt suffit à décrire tout le pipeline ; la syntaxe est plus lisible que celle de GitHub Actions.","**Intégration Forgejo native** — l'OAuth2 de Forgejo est le seul mécanisme d'authentification requis, les webhooks sont enregistrés automatiquement.","**Multi-architecture sans plugin tiers** — le label `platform: linux\u002Farm64`, dans le bloc `labels`, suffit à router un job vers un agent ARM64 ; aucune abstraction supplémentaire n'est nécessaire.","**Secrets centralisés par dépôt ou globaux** — les variables sensibles sont injectées au moment du build et n'apparaissent jamais dans le fichier YAML versionné.","**Licence Apache 2.0** — code source auditable, communauté fork active, sans dépendance à un éditeur propriétaire.",{"type":34,"title":49,"body":50},"Prérequis chiffrés : VPS, Forgejo et réseau","Woodpecker CI s'installe sur le même VPS que Forgejo ou sur un serveur dédié. Pour les deux services combinés, prévoyez 1 Go de RAM minimum et 2 Go pour un usage confortable avec plusieurs dépôts actifs en parallèle. Côté logiciel : Docker Engine 24 ou supérieur, Docker Compose v2 (la commande `docker compose`, pas `docker-compose`), un sous-domaine dédié à Woodpecker — par exemple `ci.votre-domaine.com` — pointant vers l'IP du VPS, le port 443 ouvert pour HTTPS et un accès SSH. Forgejo doit être accessible depuis le conteneur Woodpecker : soit via le réseau Docker interne si les deux services partagent le même hôte, soit via son URL publique HTTPS si Woodpecker est sur un VPS distinct. Woodpecker CI v3 intègre un pilote Forgejo dédié (`WOODPECKER_FORGEJO=true`) : utilisez une version de Forgejo encore maintenue et, si les deux services partagent l'hôte, autorisez les webhooks locaux dans Forgejo (`ALLOWED_HOST_LIST=external,loopback` dans la section `[webhook]` de `app.ini`).",{"type":34,"title":52,"body":53},"Woodpecker CI vs Forgejo Actions : quand utiliser quoi","Forgejo Actions — disponible depuis Forgejo v1.19 en mode expérimental, stabilisé progressivement — reproduit la syntaxe GitHub Actions : si vos équipes ont déjà des workflows `.github\u002Fworkflows\u002F` en production, la migration est quasi transparente. Forgejo Actions est le choix naturel pour un parc de dépôts qui cohabite avec GitHub ou qui réutilise des actions publiques du marketplace. Woodpecker CI répond à des besoins différents : sa syntaxe YAML est plus directe, moins chargée de concepts hérités de GitHub, et son architecture serveur-agent permet de découpler la forge git du moteur de CI — utile lorsque plusieurs forges (Forgejo, Gitea, GitLab) doivent partager le même parc de runners. Woodpecker est également plus adapté aux scénarios de build multi-architecture, où l'on veut aiguiller explicitement un job vers un agent ARM ou x86. En résumé : choisissez Forgejo Actions si la compatibilité GitHub Actions est prioritaire, et Woodpecker CI si vous préférez une syntaxe épurée, un déploiement découplé, ou un parc de runners hétérogènes.",{"type":55,"title":56,"steps":57},"steps","Déployer Woodpecker CI sur votre VPS",[58,61,64,67,70,73,76,79],{"title":59,"body":60},"Créer une OAuth App dans Forgejo","Dans Forgejo, allez dans Paramètres → Applications → Gérer les applications OAuth2. Donnez un nom à l'application (par exemple `woodpecker`) et renseignez l'URL de redirection : `https:\u002F\u002Fci.votre-domaine.com\u002Fauthorize`. Notez le Client ID et le Client Secret générés ; ils seront utilisés dans les variables d'environnement du serveur Woodpecker.",{"title":62,"body":63},"Générer un secret partagé serveur-agent","Générez une chaîne aléatoire robuste : `openssl rand -hex 32`. Cette valeur sera renseignée en tant que `WOODPECKER_AGENT_SECRET` à la fois dans le service serveur et dans le service agent ; elle authentifie la communication gRPC entre les deux. Notez-la dans un gestionnaire de secrets ou un fichier `.env` non versionné.",{"title":65,"body":66},"Créer le répertoire et le docker-compose.yml","Créez le répertoire `\u002Fopt\u002Fwoodpecker\u002F` et placez-y un fichier `docker-compose.yml`. Le service `woodpecker-server` utilise l'image `woodpeckerci\u002Fwoodpecker-server:v3` et écoute sur les ports 8000 (UI) et 9000 (gRPC) : ne les publiez pas sur l'IP publique, le reverse proxy et l'agent les joignent par le réseau Docker. Renseignez les variables `WOODPECKER_FORGEJO=true`, `WOODPECKER_FORGEJO_URL` (URL publique de Forgejo), `WOODPECKER_FORGEJO_CLIENT` (Client ID OAuth2), `WOODPECKER_FORGEJO_SECRET` (Client Secret OAuth2), `WOODPECKER_AGENT_SECRET` et `WOODPECKER_HOST=https:\u002F\u002Fci.votre-domaine.com`. Le service `woodpecker-agent` utilise l'image `woodpeckerci\u002Fwoodpecker-agent:v3`, monte `\u002Fvar\u002Frun\u002Fdocker.sock` et reçoit `WOODPECKER_SERVER=woodpecker-server:9000` ainsi que le même `WOODPECKER_AGENT_SECRET`.",{"title":68,"body":69},"Configurer le reverse proxy HTTPS","Configurez Traefik ou Caddy pour terminer le TLS sur `ci.votre-domaine.com` et proxifier vers `woodpecker-server:8000`. Avec Caddy, un bloc minimal suffit : `ci.votre-domaine.com { reverse_proxy woodpecker-server:8000 }`. Ne jamais exposer directement le port 8000 sur l'IP publique ; le port 9000 (gRPC) doit rester accessible uniquement sur le réseau Docker interne.",{"title":71,"body":72},"Démarrer la stack","Dans `\u002Fopt\u002Fwoodpecker`, exécutez `docker compose up -d`. Vérifiez les logs avec `docker compose logs -f woodpecker-server` jusqu'à voir la ligne `starting http server ...`. Côté agent, `docker compose logs -f woodpecker-agent` doit afficher `starting Woodpecker agent`, puis l'agent apparaît dans la liste des agents de l'administration Woodpecker ; s'il n'y apparaît pas dans les trente secondes, vérifiez que `WOODPECKER_AGENT_SECRET` est identique dans les deux services.",{"title":74,"body":75},"Se connecter et activer le premier dépôt","Ouvrez `https:\u002F\u002Fci.votre-domaine.com` et connectez-vous avec votre compte Forgejo via OAuth2. Dans le dashboard, cliquez sur « Ajouter un dépôt », sélectionnez le projet à activer. Woodpecker enregistre automatiquement un webhook dans Forgejo pour déclencher les builds sur chaque push ou pull request.",{"title":77,"body":78},"Ajouter le fichier .woodpecker.yaml dans le dépôt","À la racine du dépôt, créez `.woodpecker.yaml`. Exemple minimal avec trois étapes : `lint` (image `node:24`, commande `npm run lint`), `test` (image `node:24`, commande `npm test`) et `deploy` conditionnel à la branche `main` qui lance un script SSH distant. Poussez le fichier : un pipeline se déclenche immédiatement dans Woodpecker et son résultat apparaît dans l'interface ainsi que dans le statut de commit dans Forgejo.",{"title":80,"body":81},"Vérifier la persistance des données","Par défaut, Woodpecker stocke sa base SQLite dans le conteneur. Pour une installation durable, montez un volume nommé sur `\u002Fvar\u002Flib\u002Fwoodpecker` dans le service serveur et sauvegardez ce volume régulièrement. Un redémarrage ou une mise à jour de l'image sans volume nommé efface l'historique des builds et la configuration des dépôts activés.",{"type":34,"title":83,"body":84},"Écrire votre premier pipeline .woodpecker.yaml","Un fichier `.woodpecker.yaml` décrit une suite d'étapes exécutées séquentiellement dans des conteneurs Docker distincts. Chaque étape possède un nom, une image et une liste de commandes. Les étapes peuvent partager le workspace (répertoire cloné) via un volume monté automatiquement par Woodpecker. Pour un projet Node.js, un pipeline de base comprend une étape `lint` (`node:24`, `npm ci && npm run lint`), une étape `test` (`node:24`, `npm test`) et une étape `build` (`node:24`, `npm run build`). Pour un projet Docker, ajoutez une étape qui utilise le plugin officiel `woodpeckerci\u002Fplugin-docker-buildx` pour construire et pousser l'image vers un registre. Le déclenchement conditionnel s'exprime avec le bloc `when` : `when: { branch: main, event: push }` limite l'étape de déploiement à la branche principale sur les push directs, en excluant les pull requests.",{"type":34,"title":86,"body":87},"Secrets et variables d'environnement dans les pipelines","Woodpecker distingue trois niveaux de secrets : les secrets de dépôt (visibles uniquement dans les pipelines du dépôt concerné), les secrets d'organisation (communs aux dépôts d'une organisation) et les secrets globaux (accessibles à tous les dépôts, réservés aux administrateurs de l'instance, à créer avec prudence). Un secret est déclaré dans le dashboard — section Secrets du dépôt — puis référencé dans le pipeline avec la syntaxe `from_secret`. Par exemple, une clé SSH de déploiement nommée `deploy_key` s'injecte dans une étape via `environment: { SSH_KEY: { from_secret: deploy_key } }`. Par défaut, les secrets ne sont pas transmis aux pipelines de pull request (sauf si vous activez l'événement `pull_request` sur le secret), ce qui évite l'exfiltration par un contributeur malveillant. Pour les variables non sensibles qui doivent être partagées entre plusieurs dépôts, utilisez la variable `WOODPECKER_ENVIRONMENT` au niveau du serveur : les paires `cle:valeur`, séparées par des virgules, renseignées là sont disponibles dans tous les pipelines sans déclaration dans le YAML.",{"type":89,"body":90},"tip","Placez le serveur Woodpecker derrière Traefik ou Caddy en HTTPS et ne l'exposez jamais directement sur le port 8000. Laissez l'inscription fermée (`WOODPECKER_OPEN=false`, valeur par défaut) ou, si vous l'ouvrez, limitez-la à vos organisations Forgejo avec `WOODPECKER_ORGS` ; désignez les administrateurs avec `WOODPECKER_ADMIN`. Stockez tous les secrets de pipeline (tokens SSH, clés d'API de déploiement, mots de passe de registre Docker) dans les secrets de dépôt du dashboard Woodpecker — ils sont injectés en variable d'environnement lors du build sans apparaître dans le `.woodpecker.yaml` versionné. Enfin, montez un volume Docker nommé pour persister la base de données SQLite de Woodpecker : un redémarrage sans volume efface l'historique des builds.",{"type":34,"title":92,"body":93},"Runners multi-architecture : x86_64 et ARM64","Woodpecker CI v3 supporte nativement les agents multi-architecture : chaque agent annonce sa plateforme au serveur (`linux\u002Famd64`, `linux\u002Farm64`, `linux\u002Farm\u002Fv7`) et le serveur route les jobs vers l'agent dont la plateforme correspond. Pour déclarer un job ARM64, ajoutez `labels: { platform: linux\u002Farm64 }` au niveau du workflow dans `.woodpecker.yaml` (l'ancienne clé `platform` de premier niveau a été retirée en v3). Si vous disposez d'un VPS ARM (Ampere, Raspberry Pi 4 ou serveur Hetzner ARM) et d'un VPS x86_64, déployez un agent sur chacun avec le même `WOODPECKER_AGENT_SECRET` et laissez le serveur répartir les builds. Un agent distant joint le port gRPC 9000 du serveur par Internet : chiffrez alors ce flux en TLS (`WOODPECKER_GRPC_SECURE=true` côté agent) et n'ouvrez ce port qu'à l'IP de l'agent. Ce mécanisme est utile pour cross-compiler des binaires, tester la compatibilité d'une image Docker sur plusieurs architectures, ou valider un package système. Le plugin `woodpeckerci\u002Fplugin-docker-buildx` s'appuie sur QEMU pour aller plus loin et produire des images multi-arch depuis un seul agent, mais les builds natifs sur l'architecture cible sont toujours plus rapides.",{"type":34,"title":95,"body":96},"Dépannage : cinq erreurs fréquentes","Cinq problèmes reviennent régulièrement lors de l'installation ou de l'utilisation de Woodpecker CI. Premier : l'agent ne se connecte pas au serveur (`agent could not auth`). Cause la plus fréquente : `WOODPECKER_AGENT_SECRET` n'est pas identique dans les deux services. Vérifiez les variables avec `docker compose config | grep WOODPECKER_AGENT_SECRET` (les images Woodpecker sont construites sur `scratch`, sans commande `env`). Deuxième : la connexion OAuth2 échoue avec `Error while authenticating against OAuth provider`. Cause probable : l'URL de redirection dans l'application OAuth2 Forgejo ne correspond pas exactement à `WOODPECKER_HOST`. Vérifiez l'absence de barre oblique finale et la cohérence du schéma HTTPS. Troisième : les pipelines restent bloqués en `pending`. L'agent est peut-être connecté mais les `labels` du workflow (par exemple `platform`) ne correspondent à aucun agent ; retirez ceux qui ne sont pas nécessaires. Quatrième : les secrets ne sont pas injectés dans les étapes. Par défaut, un secret n'est transmis qu'aux événements `push`, `tag` et `deployment`, jamais aux pull requests. Vérifiez que l'événement déclencheur est bien `push` ou `tag`. Cinquième : après une montée de version v3.18, les logs de builds anciens sont absents. Cette version inclut une migration du stockage des logs, longue selon le nombre de lignes stockées : sauvegardez le volume de données avant la mise à jour, prévoyez une interruption de service et laissez la migration se terminer avant de conclure à une perte.",{"type":34,"title":98,"body":99},"Déployer Woodpecker sur un VPS ServOrbit","Woodpecker CI s'installe manuellement, via Docker Compose, sur un VPS Cloud ServOrbit avec IP fixe. Une fois le VPS provisionné, il suffit de pointer l'URL `WOODPECKER_FORGEJO_URL` vers votre forge Forgejo existante et de renseigner les clés OAuth2 pour que les pipelines commencent à s'exécuter. Cette intégration est particulièrement utile pour les agences ou les équipes techniques qui souhaitent isoler le moteur CI du serveur de forge : Forgejo sur un VPS, Woodpecker sur un second, les deux communiquant via HTTPS. Les ressources du VPS sont ajustables à tout moment depuis l'espace client — ajout de RAM ou de vCPU sans réinstallation — ce qui permet de dimensionner le parc de runners en fonction de la charge réelle des builds.",{"type":34,"title":101,"body":102},"De la forge git au déploiement continu : une stack souveraine complète","Forgejo gère le code, les issues et les revues de PR ; Woodpecker CI orchestre les pipelines de test et de déploiement. Les deux communiquent par OAuth2 et webhooks sur votre propre réseau, sans dépendance à GitHub, GitLab ou à un service d'intégration cloud. Cette stack auto-hébergée répond aux contraintes de souveraineté des agences et des équipes techniques qui ne souhaitent pas voir leur propriété intellectuelle ou leurs secrets d'intégration transiter par des plateformes externes. Avec Woodpecker CI v3 et une version maintenue de Forgejo, vous disposez d'un environnement de développement complet — forge git, CI\u002FCD, registry Docker si nécessaire — entièrement maîtrisé, sur un ou deux VPS, pour un coût mensuel prévisible et sans quota de minutes de build.","Lancez votre stack CI\u002FCD sur un VPS ServOrbit","Un VPS Cloud ServOrbit avec Docker préconfiguré et IP fixe vous permet de déployer Forgejo et Woodpecker CI en quelques minutes, avec des ressources ajustables à mesure que vos pipelines se multiplient.","Déployer sur un VPS ServOrbit","\u002Fvps-cloud",[108,133,150],{"id":109,"slug":110,"slugs":111,"title":115,"excerpt":116,"readTime":117,"views":118,"isPinned":19,"noindex":19,"publishedAt":119,"updatedAt":120,"category":121,"categories":127,"featuredImage":28,"bgImage":29,"posterImage":129,"relatedSolution":130},74,"heberger-gitea",{"fr":110,"en":112,"ar":113,"es":114},"host-gitea-on-your-own-vps","استضافة-gitea-على-خادم-vps-الخاص-بك","alojar-gitea-en-un-vps","Héberger Gitea sur votre propre VPS en 2026","Déployez Gitea 1.25 sur VPS avec Docker et SSL. Guide : Gitea Actions CI\u002FCD, comparatif Gitea vs Forgejo v16, administration quotidienne, dépannage SSH et HTTPS.",13,1,"2026-04-07T00:00:00+00:00","2026-11-08T16:32:50+00:00",{"id":122,"name":123,"slug":124,"color":125,"icon":126},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[128],{"id":122,"name":123,"slug":124,"color":125,"icon":126},"\u002Fblog\u002Fcovers\u002Fheberger-gitea-poster.svg",{"categorySlug":131,"appSlug":132},"developpement","gitea",{"id":134,"slug":135,"slugs":136,"title":140,"excerpt":141,"readTime":142,"views":143,"isPinned":19,"noindex":19,"publishedAt":144,"updatedAt":145,"category":146,"categories":147,"featuredImage":28,"bgImage":29,"posterImage":149,"relatedSolution":28},75,"heberger-forgejo",{"fr":135,"en":137,"ar":138,"es":139},"host-forgejo-on-your-own-vps","استضافة-forgejo-على-خادم-vps-الخاص-بك","alojar-forgejo-en-un-vps","Héberger Forgejo sur votre VPS : guide complet 2025","Installez Forgejo sur votre VPS avec Docker, SSL, runners Actions et sécurité renforcée. Guide pas-à-pas de 1900 mots pour une forge Git souveraine.",10,9,"2026-04-06T00:00:00+00:00","2026-11-08T01:13:14+00:00",{"id":122,"name":123,"slug":124,"color":125,"icon":126},[148],{"id":122,"name":123,"slug":124,"color":125,"icon":126},"\u002Fblog\u002Fcovers\u002Fheberger-forgejo-poster.svg",{"id":151,"slug":152,"slugs":153,"title":157,"excerpt":158,"readTime":159,"views":160,"isPinned":19,"noindex":19,"publishedAt":161,"updatedAt":162,"category":163,"categories":164,"featuredImage":28,"bgImage":29,"posterImage":166,"relatedSolution":167},3,"installer-n8n-vps",{"fr":152,"en":154,"ar":155,"es":156},"install-n8n-on-vps-with-docker-complete-2026-guide","تثبيت-n8n-على-vps-مع-docker-دليل-شامل-2026","instalar-n8n-en-vps-con-docker","Installer n8n sur VPS avec Docker : guide complet 2026","Déployez n8n sur VPS avec Docker, reverse proxy et HTTPS. Crash V8, 502 nginx, migration npm vers Docker et sécurisation des exécutions persistées (advisory août 2026).",19,4,"2026-06-05T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":18,"name":23,"slug":24,"color":25,"icon":24},[165],{"id":18,"name":23,"slug":24,"color":25,"icon":24},"\u002Fblog\u002Fcovers\u002Finstaller-n8n-vps-poster.svg",{"categorySlug":24,"appSlug":168},"n8n",true,1794270811198]