--- title: "Migration BitBucket Cloud vers Forgejo." canonical: "https://blog.kaptus.net/space/BKAP/blog/806944770/Migration%20BitBucket%20Cloud%20vers%20Forgejo." format: markdown --- > Macro (toc) # 1. Introduction. Pendant des années, j’ai hébergé mes dépôts `Git` sur `Bitbucket Server` directement sur ma propre infrastructure. Ce choix me permettait : - de garder une maîtrise complète de mes sources, - de l’accès aux données et de la disponibilité du service. L’outil répondait parfaitement à mes besoins et s’intégrait naturellement dans une logique d’auto-hébergement. Mais avec l’évolution de la stratégie d’Atlassian et l’**arrêt progressif des solutions serveur au profit du Cloud,** j’ai finalement été contraint de migrer vers **Bitbucket Cloud**. Cette transition semblait être la voie la plus simple pour continuer à utiliser l’écosystème Atlassian. Ce changement a aussi marqué une perte importante de contrôle sur mon infrastructure de développement. **Même si Bitbucket Cloud est une excellente solution**, plusieurs points m’ont poussé à remettre en question ce modèle : - mes dépôts sont hébergés sur une infrastructure cloud dont je ne maîtrise ni la disponibilité ni les évolutions ; - je reste dépendant des choix stratégiques et tarifaires d’Atlassian ; - certaines fonctionnalités autrefois disponibles en auto-hébergé deviennent conditionnées à des offres cloud ; - et plus globalement, je souhaite revenir vers une approche plus ouverte, pérenne et souveraine. > ℹ️ Suite à quelques pannes subit sur le **Cloud Atlassian**, je me suis retrouvé sans accès à mes codes sources pendant plus d’une demi-journée fin d’année 2025. C’est dans ce contexte que j’ai décidé de migrer mes dépôts vers `Forgejo`, une forge `Git` open source, communautaire et auto-hébergeable issue de `Gitea`. Dans cet article, je vais revenir sur les raisons de cette migration, la préparation technique, les étapes de transfert depuis Bitbucket Cloud ainsi que les bénéfices obtenus après le passage à Forgejo. # **2. Étude synthétique des solutions Open Source pour l’auto-hébergement de dépôts Git** L’auto-hébergement d’une forge logicielle revient aujourd’hui au centre des préoccupations de nombreuses équipes techniques et développeurs indépendants. Les motivations sont multiples : souveraineté numérique, maîtrise des coûts, indépendance vis-à-vis des éditeurs `SaaS`, **confidentialité du code source **ou encore **pérennité des outils**. Le marché des solutions open source s’est considérablement structuré ces dernières années autour de plusieurs acteurs majeurs : `GitLab CE`, `Forgejo`, `Gitea`, `Gogs` ou encore `OneDev`. Chacune répond à des besoins différents, allant du simple hébergement `Git` léger jusqu’à la plateforme `DevOps` complète. > ℹ️ Ce comparatif reflète avant tout mon besoin et mon contexte d’utilisation. D’autres solutions peuvent parfaitement convenir selon la taille de l’équipe, les contraintes d’infrastructure ou les besoins `DevOps`. ## **2.1. Les principaux critères de comparaison** Avant de choisir une solution, plusieurs critères doivent être évalués : | **Critère** | **Description** | | --- | --- | | Simplicité d’installation | Déploiement Docker, VM ou Kubernetes | | Consommation de ressources | RAM, CPU, stockage | | Fonctionnalités DevOps | CI/CD, registry, tickets, wiki | | Gouvernance du projet | Communautaire ou piloté par une entreprise | | Pérennité | Activité du projet et communauté | | Facilité de migration | Import GitHub, GitLab, Bitbucket | | Administration | Sauvegarde, mises à jour, LDAP/SSO | | Philosophie | Open source “pur”, SaaS hybride, modèle commercial | ## **2.2. Forgejo** | **Présentation** | **Points forts** | **Limites** | **Cas d’usage idéal** | | --- | --- | --- | --- | | `Forgejo` est un fork communautaire de `Gitea` apparu après des interrogations sur la gouvernance et l’orientation commerciale de `Gitea`. Le projet met fortement l’accent sur :
- la transparence ; - la gouvernance ouverte ; - la souveraineté numérique ; - et l’indépendance vis-à-vis des modèles SaaS.
`Forgejo` est aujourd’hui considéré comme l’une des références du `self-hosting Git `léger et moderne. | - Très faible consommation de ressources (~256–512 Mo RAM) - Installation extrêmement simple - Compatible Docker et Kubernetes - Interface proche de GitHub/Gitea - Migration native depuis Bitbucket, GitHub ou GitLab - Bon support ARM/Raspberry Pi - Gouvernance communautaire forte - Orientation “fédération” et `ActivityPub` | - `CI/CD` encore moins mature que `GitLab` - Écosystème plus réduit - Fonctionnalités `DevSecOps` limitées - Moins adapté aux très grandes entreprises | - Développeur indépendant - Homelab - PME - Hébergement souverain - Migration depuis `Bitbucket Cloud` | ## **2.3. Gitea** | **Présentation** | **Points forts** | **Limites** | **Cas d’usage idéal** | | --- | --- | --- | --- | | `Gitea` est historiquement le fork de `Gogs` devenu une forge `Git` légère très populaire. Il propose :
- pull requests ; - gestion d’issues ; - wiki ; - registry ; - Actions `CI/CD` ; - administration simplifiée. | - Très mature - Léger et rapide - Large communauté - Déploiement simple - Bon compromis fonctionnalités/performance | - Gouvernance parfois critiquée - Orientation plus commerciale - Certaines tensions communautaires ont conduit à la naissance de `Forgejo` | - Petites équipes - Infrastructure légère - Auto-hébergement simple | ## **2.4. GitLab Community Edition (CE)** | **Présentation** | **Points forts** | **Limites** | **Cas d’usage idéal** | | --- | --- | --- | --- | | `GitLab CE` est la version open source de `GitLab`. Contrairement à `Forgejo` ou `Gitea`, `GitLab` vise une plateforme `DevOps` complète intégrant :
- `Git` ; - `CI/CD `; - `registry Docker `; - sécurité ; - `boards Agile` ; - gestion de projet ; - monitoring. | - `CI/CD` extrêmement puissant - Écosystème `DevOps` complet - Intégration `Kubernetes` - Fonctionnalités entreprise - Très adapté aux équipes structurées | - Très gourmand en ressources (**4 à 8 Go RAM** minimum) - Maintenance plus complexe - Montées de version parfois lourdes - Infrastructure plus coûteuse | - Entreprises - Équipes `DevOps` matures - Besoins `CI/CD` avancés | ## **2.5. Gogs** | **Présentation** | **Points forts** | **Limites** | **Cas d’usage idéal** | | --- | --- | --- | --- | | `Gogs` est l’ancêtre de `Gitea`. Le projet reste maintenu mais avec un rythme plus faible. Il privilégie la simplicité absolue. | - Ultra léger - Déploiement minimaliste - Très peu de dépendances | - Fonctionnalités limitées - Écosystème réduit - Moins dynamique aujourd’hui | - Serveur `Git` minimaliste - Environnements embarqués - Usage personnel simple | ## **2.6. OneDev** | **Présentation** | **Points forts** | **Limites** | **Cas d’usage idéal** | | --- | --- | --- | --- | | `OneDev` est une forge `Git` plus récente qui cherche à se différencier par :
- une interface moderne ; - des fonctionnalités de navigation avancée dans le code ; - une forte intégration `CI/CD`. | - Recherche de code avancée - Expérience développeur moderne - Pipeline intégré performant | - Communauté plus petite - Moins documenté - Adoption encore limitée | - Équipes de développement techniques - Projets nécessitant une CI/CD intégrée sans déployer GitLab - Organisations recherchant une forge moderne avec recherche avancée dans le code - Environnements intermédiaires entre “forge légère” et “plateforme DevOps complète” | ## **2.7. Comparaison synthétique** | **Solution** | **Ressources** | **CI/CD** | **Gouvernance** | **Complexité** | **Public cible** | **Site officiel** | | --- | --- | --- | --- | --- | --- | --- | | `Forgejo` | Très faible | Moyen | Communautaire | Faible | Devs, PME, souveraineté | [https://forgejo.org/](https://forgejo.org/) | | `Gitea` | Très faible | Moyen | Mixte | Faible | PME, homelab | [https://about.gitea.com/](https://about.gitea.com/) | | `GitLab CE` | Élevée | Excellent | Entreprise | Élevée | Grandes équipes | [https://about.gitlab.com/install/](https://about.gitlab.com/install/) | | `Gogs` | Minimal | Faible | Communautaire | Très faible | Git simple | [https://gogs.io/getting-started/introduction](https://gogs.io/getting-started/introduction) | | `OneDev` | Moyen | Bon | Communautaire | Moyenne | Équipes techniques | [https://onedev.io/](https://onedev.io/) | # 3. Installation. L’installation sera faite sur une VM PROXMOX : | **vCPUs** | **Mémoire** | **Espace disque** | | --- | --- | --- | | `2` | `8Go` | `100Go` | **Récupération du binaire :** ```shell cd /opt/naos/archives/src/ wget https://codeberg.org/forgejo/forgejo/releases/download/v15.0.1/forgejo-15.0.1-linux-amd64 chmod +x forgejo-15.0.1-linux-amd64 ``` ![image-20251220-175814.png](media://bb5feefa-8393-4853-baba-6c1824ef15fc) **Vérification de la signature : ** ```shell sh /opt/naos/archives/firewall/stop_firewall.sh gpg --keyserver keys.openpgp.org --recv EB114F5E6C0DC2BCDD183550A4B61A2DC5923710 ``` ![image-20251220-180436.png](media://f19d7e2c-eeac-4273-b144-bac0cfb5ef74) ```shell wget https://codeberg.org/forgejo/forgejo/releases/download/v15.0.1/forgejo-15.0.1-linux-amd64.asc gpg --verify forgejo-15.0.1-linux-amd64.asc forgejo-15.0.1-linux-amd64 ``` ![image-20251220-180548.png](media://216f4d93-ecf0-479b-b423-3246a3c46f51) **Installation :** ```shell cp forgejo-15.0.1-linux-amd64 /usr/local/bin/forgejo chmod 755 /usr/local/bin/forgejo apt install git git-lfs ``` ![image-20251220-181020.png](media://5755635a-ea7c-4c3d-a0c9-86aac48c7ef5) ```shell adduser --system --shell /bin/bash --gecos 'Git Version Control' \ --group --disabled-password --home /home/git git mkdir /var/lib/forgejo chown git:git /var/lib/forgejo && chmod 750 /var/lib/forgejo mkdir /etc/forgejo chown root:git /etc/forgejo && chmod 770 /etc/forgejo ``` **Préparation de la base de données :** Les requêtes SQL pour la création de la base de données : ```sql SET old_passwords=0; CREATE USER 'forgejo'@'%' IDENTIFIED BY 'xxxxxxxxxxxxxxxxxxxxxx'; SET old_passwords=0; CREATE USER 'forgejo'@'127.0.0.1' IDENTIFIED BY 'xxxxxxxxxxxxxxxxxxxxxx'; SET old_passwords=0; CREATE USER 'forgejo'@'localhost' IDENTIFIED BY 'xxxxxxxxxxxxxxxxxxxxxx'; CREATE DATABASE forgejodb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin'; GRANT ALL PRIVILEGES ON forgejodb.* TO 'forgejo'; FLUSH PRIVILEGES; ``` Installation du service `Forgejo` : ```shell wget -O /etc/systemd/system/forgejo.service https://codeberg.org/forgejo/forgejo/raw/branch/forgejo/contrib/systemd/forgejo.service ``` Editer le fichier : ```shell vi /etc/systemd/system/forgejo.service ``` Et activer les lignes : ```plaintext Wants=mariadb.service After=mariadb.service ``` Puis recharger la configuration de `systemd`, activer le service forgejo et le lancer : ```shell systemctl daemon-reload systemctl enable forgejo.service systemctl start forgejo.service ``` On vérifie que le service est bien démarré : ```shell systemctl status forgejo.service ``` ![image-20251221-111513.png](media://b6da8569-9b0c-4945-aa9a-c9996cee1dcb) ## 3.1. La configuration apache2. ```xml # DocumentRoot /var/www ServerName xxxxx.xxx.xx ServerAlias xxxxx.xxx.xx ServerAdmin webmaster@xxxxx.xx DirectoryIndex index.html index.php LogLevel info authz_core:debug ErrorLog "/var/log/apache2/error.log" TransferLog "/var/log/apache2/access.log" Protocols h2 http/1.1 RewriteEngine On ## SSL SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off SSLUseStapling Off ## Proxy ProxyRequests Off ProxyPreserveHost On ProxyVia Off ## RequestHeader unset Accept-Encoding RewriteCond %{HTTP:Upgrade} =websocket RewriteRule /(.*) wss://localhost:3000/$1 [P,L] ## ## Certificat generated by par KAPTUS and certified by Let's Encrypt. SSLCertificateFile /var/lib/certs/cert.pem SSLCertificateKeyFile /var/lib/certs/privkey.pem SSLCertificateChainFile /var/lib/certs/chain.pem ## Proxy authent Order deny,allow Allow from all Authtype Basic Authname "Password Required" AuthUserFile /etc/apache2/.htpasswd Require valid-user ## Require all granted ## Proxy ProxyPass / http://localhost:3000/ ProxyPassReverse / http://localhost:3000/ ## Websocket ProxyPass / wss://localhost:3000/ ProxyPassReverse / wss://localhost:3000/ ``` # 4. Configuration de Forgejo. | | | | | --- | --- | --- | | > Macro (drawio) | > Macro (drawio) | > Macro (drawio) | Une fois configurer, on va modifier le fichier de configuration à la main. ```powershell systemctl stop forgejo.service chmod 750 /etc/forgejo && chmod 640 /etc/forgejo/app.ini vi /etc/forgejo/app.ini ``` Ajouter les lignes : ```plaintext [repository.upload] ;; max size for files to the repo via web interface, in MB, ;; defaults to 3 (this sets a limit of about 4GB) FILE_MAX_SIZE = 4095 ;; by default 5 files can be uploaded at once, increase to 20 MAX_FILES = 20 ;; Git Operation timeout in seconds ;; increase the timeouts, so importing big repos (and presumably ;; pushing large files?) hopefully won't fail anymore [git.timeout] DEFAULT = 3600 ; Git operations default timeout seconds MIGRATE = 6000 ; Migrate external repositories timeout seconds MIRROR = 3000 ; Mirror external repositories timeout seconds CLONE = 3000 ; Git clone from internal repositories timeout seconds PULL = 3000 ; Git pull from internal repositories timeout seconds GC = 600 ; Git repository GC timeout seconds ``` entre les modules : - [server] - [repository] On désactive aussi la création des utilisateurs depuis le site en modifiant la variable `DISABLE_REGISTRATION = true` dans le module `[service]`. On relance le service : ```shell systemctl start forgejo.service ``` # 5. Migration des dépôts `BITBUCKET`. ## 5.1. Génération de la clé API TOKEN. Depuis `BITBUCKET` : [https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) > Macro (drawio) | | | | | --- | --- | --- | | ![image-20260102-175327.png](media://481c45a5-fef4-4aee-a7fa-6f246651d35e) | ![image-20260102-175433.png](media://93a1f16f-957a-4f50-8aec-bdc5ae72a622) | ![image-20260102-175524.png](media://7859fb9c-dacd-455b-ae6f-8f5bb2f801fb) | | ![image-20260102-175605.png](media://8ad577b2-dfa0-4ff5-a6c9-9aa23d4026b0) | ![image-20260102-175638.png](media://da81c152-d1b0-4654-a2b3-93c6b8cfaea4) | | > ⚠️ Penser à copier le token car il ne sera plus disponible après avoir fermé la fenêtre. ![image-20260102-175823.png](media://7dbd22ab-1619-4160-9170-2c8204687f63) ## 5.2. Procédure de migration. > ℹ️ 1/2/2026 → Dans `FORGEJO`, je ne suis pas arrivé à attacher des dépôts `GIT` à des projets. Du coup, l’alternative est de créer une organisation spécifique pour chaque projets : > ℹ️ > ℹ️ ![image-20260104-095116.png](media://c62e6b6f-00df-4c05-805d-81afe004667d) ### 5.2.1. Création d’une organisation. | | | | --- | --- | | ![image-20260104-095234.png](media://30a9f24b-facf-4ae9-8199-ecc81b7a395a) | ![image-20260104-095341.png](media://01e493d4-6460-4490-88fa-9a96f2c0b366) | | ![image-20260104-095557.png](media://c03e80f9-6586-48ad-a62d-1819ae553548) | | ![image-20260104-095734.png](media://2b1d7b09-57a0-4839-953a-6818fbd2f1b4) | ### 5.2.2. Migration d’un dépôt `BITBUCKET`. Se positionner sur l’organisation souhaitée et cliquer sur le bouton : ![image-20260104-095912.png](media://aba03668-70b1-4842-ae93-490a4244f0d7) Puis sélectionner : ![image-20260104-100019.png](media://12c28621-5fb2-4e08-8c59-cd0a3f787bc9) Et remplir les champs du formulaire : > Macro (drawio) En cours de migration : ![image-20260104-100303.png](media://fa118318-b3e6-4131-b096-965311033a4d) Fin de migration : > Macro (drawio) # 6. En conclusion. Cette migration vers `Forgejo` représente surtout un retour à une philosophie d’hébergement que j’avais progressivement mise de côté pour des raisons de commodités, avec l’abandon de `Bitbucket Server` au profit du `Cloud Atlassian`. Reprendre la maîtrise de mes dépôts `Git`, de mon infrastructure et de mes données était devenu un objectif important. L’un des points essentiels dans cette démarche concernait également **la confidentialité des codes sources**. Même si les plateformes cloud proposent des garanties de sécurité élevées, le fait d’héberger des projets parfois sensibles sur une infrastructure tierce implique nécessairement une forme de dépendance et une perte de contrôle. En auto-hébergeant mes dépôts, je sais précisément où sont **stockées mes données**, qui peut **y accéder**, comment **les sécuriser** et comment elles sont **sauvegardées**. Cette maîtrise est devenue un critère déterminant dans mon choix. Après avoir étudié plusieurs solutions open source, `Forgejo` s’est imposé comme le meilleur compromis : - léger et simple à administrer ; - entièrement open source ; - sans dépendance à une offre commerciale propriétaire ; - moderne et compatible avec les usages actuels. J’utilise désormais `Forgejo` en production depuis `janvier 2026` et, jusqu’à présent, je n’ai rencontré aucun problème particulier. Les mises à jour sont simples à gérer, bien documentées et surtout totalement maîtrisées. Les différentes montées de version effectuées jusqu’ici se sont déroulées sans difficulté majeure, ce qui confirme la maturité et la stabilité de la solution dans un contexte d’usage quotidien. > ⚠️ Bien entendu, `Forgejo` ne propose pas encore un écosystème `CI/CD` aussi riche ou avancé que `GitLab CI `ou `GitHub Actions`. Ce point peut représenter une limite pour certaines organisations ayant des besoins `DevOps` très poussés. Dans mon cas, cette absence n’est pas bloquante aujourd’hui, car mes besoins en intégration et déploiement continus restent relativement simples. J’ai également particulièrement apprécié la gouvernance communautaire du projet et son orientation clairement tournée vers la souveraineté numérique. Là où certaines plateformes suivent un modèle “open core” ou restent fortement dépendantes d’un éditeur unique, `Forgejo` revendique une approche plus ouverte, transparente et durable. Avec le recul, ce choix semble d’ailleurs conforté par les initiatives récentes de plusieurs administrations européennes autour de `Forgejo`. En 2026, [le gouvernement néerlandais a lancé sa propre plateforme souveraine](https://korben.info/les-pays-bas-migrent-leur-code-vers-forgejo-et-claquent-la-porte-de-github.html) `code.overheid.nl`, basée sur `Forgejo`, afin de réduire sa dépendance aux plateformes américaines et de reprendre le contrôle de l’hébergement de ses codes sources. Cette initiative montre que l’auto-hébergement des forges `Git` n’est plus seulement un sujet réservé aux passionnés d’open source ou aux environnements de laboratoire, mais devient progressivement un véritable enjeu stratégique pour les organisations et les administrations européennes.