Pourquoi la panne du 17 août 2026 change la question
Le 17 août 2026, à partir de 9 h 40 heure de la côte Est, GitHub a connu une défaillance de capacité dans son datacenter de la zone Central US. La plateforme a atteint un pic de trafic que son infrastructure n'a pas absorbé : environ 20 % d'erreurs sur les expériences web et les appels API, jusqu'à 50 % sur les téléchargements d'archives. GitHub Actions a été l'un des services les plus durablement touchés. L'ensemble des services n'est revenu à la normale qu'à 17 h 27, soit 7 h 47 après le début de l'incident — reconnu publiquement par GitHub le 20 août 2026.
DanubeData, une société d'infrastructure de données, a publié un retour d'expérience précis : l'incident a révélé une dépendance cachée de leur plan de contrôle à GitHub. En réponse, ils ont migré 9 dépôts — représentant 333 pull requests et environ 400 Mo d'historique Git — vers une instance Forgejo auto-hébergée, en une seule journée. Leur pipeline de build principal et leur workflow de déploiement en production ont suivi dans la foulée.
La question n'est plus « est-ce que GitHub peut tomber ? » mais « quelle est notre exposition si c'est le cas ? ». Forgejo Actions répond à cette question en déplaçant l'exécution de la CI/CD sur votre propre infrastructure.
Bénéfices d'un Forgejo auto-hébergé pour votre CI/CD
- Disponibilité indépendante de GitHub — une panne de la plateforme n'interrompt ni vos builds ni vos déploiements.
- Syntaxe YAML compatible — la majorité des workflows GitHub Actions s'exécutent sans modification sur Forgejo Actions.
- Coût fixe et prévisible — chaque minute de pipeline est une ressource déjà payée sur votre VPS, pas une ligne de facturation à la consommation.
- Confidentialité des pipelines — le code source, les secrets d'environnement et les artefacts de build ne quittent pas votre infrastructure.
- Runners configurables — exécution en conteneur Docker, en processus natif ou dans un environnement LXC non disponible sur GitHub.
- Gouvernance associative — Forgejo est maintenu par Codeberg e.V., sans édition enterprise payante ni risque de pivot commercial.
Prérequis
Avant de démarrer l'installation, vérifiez que votre VPS réunit les ressources suivantes.
RAM : 2 Go minimum pour la forge seule, avec 5 à 20 développeurs et des dépôts de taille raisonnable. Comptez 4 Go si vous exécutez Forgejo Actions avec des runners qui compilent localement (Go, Rust, Java).
vCPU : 2 vCPU suffisent pour une équipe de 20 développeurs. Ajoutez 2 vCPU par runner simultané si vos builds sont CPU-intensifs.
Disque : réservez au moins 20 Go de SSD pour les dépôts, l'historique Git, les artefacts de CI et les journaux. Prévoyez 50 Go si vous hébergez plusieurs années d'historique ou des artefacts binaires volumineux.
Réseau : le port 22 reste disponible sur l'hôte (SSH système) ; Forgejo SSH sera exposé sur un port distinct, par convention 2222. Le port 443 doit être ouvert pour le reverse proxy.
Domaine : préparez un sous-domaine tel que git.votredomaine.com avec un enregistrement A pointant vers l'IP de votre VPS.
Logiciels : Docker 24+ et le plugin Compose installés sur le VPS.
Migration de GitHub vers Forgejo Actions : installation et portage
Installer Forgejo avec Docker et PostgreSQL
Créez le répertoire de travail /opt/forgejo et un sous-répertoire data. Rédigez un docker-compose.yml avec deux services : forgejo (image codeberg.org/forgejo/forgejo:latest, port interne 3000, SSH mappé sur 2222:22, volume ./data:/data, variables USER_UID=1000 et USER_GID=1000) et db (image postgres:16, volume dédié, variables POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB). Lancez docker compose up -d et surveillez docker compose logs -f forgejo jusqu'à la mention du port HTTP 3000 actif.
Configurer le reverse proxy et le certificat SSL
Avec Caddy, un seul bloc suffit : git.votredomaine.com { reverse_proxy localhost:3000 }. Le certificat Let's Encrypt est provisionné automatiquement. Avec Nginx, créez un bloc server écoutant sur 443 avec proxy_pass http://127.0.0.1:3000; et ajoutez obligatoirement proxy_read_timeout 600s; — DanubeData a rencontré un 504 faute de ce réglage, bloquant l'import à 196 pull requests sur 333. Redirigez HTTP vers HTTPS dans un bloc séparé.
Compléter l'installation initiale
Accédez à https://git.votredomaine.com. L'assistant d'installation vous demande : driver de base de données (PostgreSQL), hôte (db:5432), identifiants, URL de base HTTPS et port SSH externe (2222). Créez le compte administrateur. Pour une instance privée, désactivez l'auto-inscription dans les réglages ou en ajoutant DISABLE_REGISTRATION=true dans les variables d'environnement du service.
Migrer les dépôts GitHub
Dans l'interface Forgejo, cliquez Nouveau dépôt → Migrer. Sélectionnez GitHub comme source. Renseignez l'URL du dépôt (https://github.com/votre-org/votre-depot), un personal access token GitHub avec le scope repo, et activez la migration des pull requests, labels, jalons et releases. Pour les dépôts volumineux (> 1 Go ou > 200 pull requests), testez d'abord avec le timeout de reverse proxy à 600 s. Supprimez le dépôt incomplet et relancez si un 504 survient. Répétez pour chaque dépôt.
Enregistrer un runner Forgejo Actions
Dans Forgejo, accédez à Administration → Actions → Runners → Créer un runner. Copiez le jeton d'enregistrement. Ajoutez un service act-runner dans votre docker-compose.yml avec l'image codeberg.org/forgejo/runner:latest, les variables FORGEJO_INSTANCE_URL (URL HTTPS de votre instance) et FORGEJO_RUNNER_REGISTRATION_TOKEN. Lancez docker compose up -d act-runner. Vérifiez que le runner apparaît en statut En ligne dans l'administration.
Placer les fichiers de workflow dans le bon répertoire
Sur GitHub, vos workflows vivent dans .github/workflows/. Sur Forgejo, ils doivent être dans .forgejo/workflows/. Renommez le répertoire dans chaque dépôt migré et poussez la modification. Le reste du fichier YAML — déclencheurs on:, jobs, steps, uses: pour les actions tierces compatibles — reste identique dans la majorité des cas. Forgejo ne lit pas le répertoire .github/.
Adapter les éléments spécifiques à GitHub
Quelques points d'adaptation : remplacez les actions qui appellent l'API GitHub (gh-based) par leur équivalent Forgejo ou neutralisez-les ; supprimez tout permissions: id-token: write (Forgejo utilise enable-openid-connect dans le fichier de workflow pour l'OIDC) ; si votre workflow référence un outil absent de l'image Debian bookworm du runner, ajoutez une étape apt-get install -y <outil>. Les actions actions/checkout et actions/setup-node sont résolues nativement.
Vérifier les premiers pipelines
Créez un workflow minimal .forgejo/workflows/smoke.yml déclenché sur push, avec un seul job exécutant echo "Pipeline OK". Consultez Actions dans l'interface Forgejo. Une fois ce premier run vert, transférez vos workflows de production un par un et corrigez les écarts au fur et à mesure.
Configuration post-migration
Après avoir validé l'exécution des pipelines, trois points restent à configurer.
Webhooks et notifications : si des systèmes externes (Slack, Mattermost, un webhook de déploiement) écoutaient les événements GitHub, recréez-les dans Forgejo sous Paramètres → Webhooks. La charge utile est similaire à celle de GitHub, mais le format diffère sur quelques champs — ajustez vos endpoints de réception.
Secrets de pipeline : les secrets GitHub (menu Settings → Secrets) doivent être recréés dans Forgejo sous Paramètres du dépôt → Actions → Secrets. Pour les secrets d'organisation, utilisez Administration → Organisations → [votre org] → Paramètres → Actions → Secrets. Ne migrez jamais un secret par sa valeur dans un commit ou un fichier versionné.
Permissions des runners : par défaut, un runner enregistré au niveau instance peut exécuter des workflows pour tous les dépôts. Pour un contrôle plus fin, restreignez un runner à une organisation ou à un dépôt spécifique dans l'onglet Runners des paramètres correspondants.
Durcissement de l'instance Forgejo
Trois mesures réduisent significativement la surface d'attaque d'une instance ouverte sur internet.
Activez la 2FA obligatoire pour tous les comptes, en particulier les comptes administrateurs : Administration → Paramètres d'authentification → Exiger la 2FA.
Auditez les clés SSH enregistrées. Un utilisateur migré depuis GitHub peut avoir des clés orphelines ou périmées dans son profil. Demandez à chaque membre de l'équipe de vérifier ses clés dans Paramètres → Clés SSH/GPG et de supprimer celles qui ne correspondent plus à un appareil actif.
Activez la vérification HMAC sur tous les webhooks sortants. Dans chaque webhook, renseignez le champ Secret avec une chaîne aléatoire d'au moins 32 caractères. L'endpoint de réception doit vérifier la signature X-Gitea-Signature (header identique sur Forgejo). Sans ce contrôle, n'importe qui connaissant l'URL de votre endpoint peut déclencher une action de déploiement.
Dépannage — erreurs fréquentes
504 Gateway Timeout pendant la migration d'un dépôt. Forgejo effectue l'import de façon synchrone dans la requête HTTP. Si le reverse proxy coupe la connexion avant la fin, la migration s'interrompt et le dépôt reste dans l'état « Migration en cours ». Augmentez proxy_read_timeout à 600 s (Nginx) ou ajoutez timeouts { read_body 10m } (Caddy) avant de lancer la migration. Supprimez ensuite le dépôt incomplet et relancez.
Runner stays Offline after startup. Vérifiez que FORGEJO_INSTANCE_URL pointe vers l'URL HTTPS publique de votre instance, pas vers localhost ou l'IP interne du conteneur. Le runner doit joindre Forgejo par le même chemin qu'un navigateur externe.
Workflow not triggered after push. Vérifiez que les fichiers de workflow sont bien dans .forgejo/workflows/ et non dans .github/workflows/. Forgejo ne lit pas le répertoire .github/.
Error: this step uses an action, but the runner does not support actions. Certaines actions tierces référencées par uses: appellent l'API GitHub. Remplacez-les par un équivalent disponible sur Codeberg ou mirrorizez-les dans votre instance.
permission denied sur un script en fin de job. L'image de base du runner (Debian bookworm) ne contient pas les mêmes utilitaires que l'image Ubuntu de GitHub. Ajoutez une étape apt-get install -y <outil> en début de job, ou spécifiez une image Docker personnalisée via container:.
Pour aller plus loin
Ce guide couvre l'installation et la migration de votre CI/CD vers Forgejo Actions. Pour approfondir, les articles suivants traitent de thèmes complémentaires : l'hébergement initial de Forgejo sur VPS avec Docker et SSL, la mise en place d'un pipeline Woodpecker CI en complément de Forgejo, et la migration de vos dépôts GitHub vers une forge Git auto-hébergée.
Héberger Forgejo sur votre propre VPS — installation complète, reverse proxy et premier runner.
Pipeline Woodpecker CI sur VPS avec Forgejo — alternative à Forgejo Actions pour les équipes qui veulent séparer la forge et le moteur de CI.
Migrer ses dépôts GitHub vers Gitea ou Forgejo sur VPS — procédure de migration pas-à-pas avec l'outil officiel.
