Mise en place d’une forge personnelle avec Forgejo

Après avoir multiplié les petits projets personnels, j’ai voulu reprendre la main sur toute la chaîne de développement : héberger mes dépôts, lancer mes automatisations et suivre les Pull Requests sans dépendre uniquement de plateformes externes. J’ai donc mis en place une forge personnelle avec Forgejo, accompagnée d’un runner, de Renovate et de mon instance Hermes Agent sur VPS pour automatiser une partie des reviews.

Pourquoi Forgejo

Je cherchais une forge légère, simple à maintenir et suffisamment complète pour un usage personnel : dépôts Git, issues, Pull Requests, gestion des utilisateurs et intégration avec des runners. Forgejo répond bien à ce besoin. L’interface reste familière, la consommation est raisonnable, et l’administration est plus simple qu’une plateforme beaucoup plus lourde.

• Héberger mes dépôts personnels sur mon infrastructure.
• Garder une interface proche des forges Git classiques.
• Pouvoir ajouter de l’automatisation sans complexifier toute la stack.

Architecture Docker Compose

La plateforme repose sur trois briques : le service Forgejo, un moteur d’exécution isolé pour les jobs, et un runner chargé de lancer les automatisations. Cette séparation permet de garder la forge lisible tout en évitant de mélanger l’hébergement des dépôts et l’exécution des workflows.

• Forgejo tourne avec une image rootless, ce qui limite les privilèges du service principal.
• Les données applicatives sont conservées de façon persistante.
• L’interface web et l’accès Git en SSH sont exposés séparément, puis intégrés au reste de l’infrastructure via le reverse proxy et le bastion.
• Le runner Forgejo conserve sa configuration séparément du service principal.

Le choix Docker Compose rend la stack lisible : un service pour la forge, un service pour l’exécution des jobs, et un service pour le runner. Je peux sauvegarder les données utiles et redéployer l’ensemble sans reconstituer la configuration à la main.

Forgejo en mode rootless

J’ai choisi une approche rootless pour limiter les privilèges du service principal. Les données restent persistantes, et la configuration garde des dates cohérentes dans l’interface comme dans les logs.

L’interface web et les opérations Git en SSH restent séparées. Cela permet de distinguer clairement l’usage utilisateur, l’accès Git et l’exposition publique gérée par le reverse proxy.

Runner et Docker-in-Docker

Pour exécuter des jobs, j’ai ajouté un runner Forgejo. Il s’appuie sur un conteneur Docker-in-Docker qui expose le daemon Docker uniquement sur le réseau interne Compose. Le runner utilise ensuite ce moteur interne pour créer les environnements nécessaires aux automatisations.

Le moteur d’exécution des jobs demande de rester prudent : il doit rester isolé et réservé aux workflows que je contrôle. Dans mon cas, il sert surtout à automatiser mes propres dépôts et à éviter d’exécuter ces tâches directement sur l’hôte.

• Le runner démarre après le service Docker-in-Docker.
• Il tourne avec un utilisateur non privilégié côté runner.
• Sa configuration est séparée de celle du service principal.

Renovate pour garder les dépendances à jour

J’ai aussi mis en place Renovate pour surveiller les dépendances de mes projets. L’objectif n’est pas de tout mettre à jour automatiquement sans contrôle, mais de recevoir des Pull Requests claires, avec le changelog et le contexte nécessaire pour décider rapidement si la mise à jour est acceptable.

Sur une forge personnelle, Renovate est particulièrement utile parce qu’il évite l’accumulation de petites versions oubliées. Les mises à jour arrivent sous forme de PR, ce qui garde une trace propre des changements et permet de tester avant de fusionner.

Reviews automatiques avec Hermes Agent

Pour aller plus loin, j’ai relié la forge à mon instance Hermes Agent hébergée sur un VPS. L’idée est d’avoir une première review automatique sur les Pull Requests : repérer les changements risqués, signaler les incohérences évidentes et m’aider à relire plus vite sans remplacer la validation humaine.

Cette partie est surtout intéressante sur les PR générées par Renovate. Hermes peut donner un premier avis sur la portée du changement, ce qui me permet de prioriser les mises à jour simples et de garder plus d’attention pour les modifications qui touchent au build, à la sécurité ou à la configuration.

Points d’attention

• Sauvegarder régulièrement les données importantes de la forge et du runner.
• Limiter les dépôts et jobs autorisés à utiliser le runner.
• Surveiller le Docker-in-Docker, car il nécessite des privilèges élevés.
• Garder les tokens Renovate et Hermes séparés avec les permissions minimales nécessaires.

Bilan

Cette forge personnelle me donne une chaîne de développement plus autonome : les dépôts sont hébergés chez moi, les jobs peuvent tourner via le runner, Renovate garde les dépendances sous surveillance et Hermes Agent apporte une première lecture automatique des Pull Requests. Le tout reste assez simple à maintenir grâce à Docker Compose, tout en laissant la possibilité d’ajouter progressivement de nouveaux workflows.