Installer Forgejo LTS sur PostgreSQL derrière un proxy TLS

40 min

Par Stéphane Robert mis à jour le 16 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Pour mettre en service Forgejo 15 LTS, on déploie trois conteneurs avec Docker Compose : Forgejo, une base PostgreSQL 17 et un proxy Caddy qui porte le HTTPS. Le clonage SSH passe directement par le port 2222 de la machine, le port web 3000 de Forgejo n'est jamais publié, et le premier administrateur se crée en ligne de commande. Cette leçon s'adresse à un administrateur qui a déjà manipulé Docker et qui installe sa première forge Git.

La procédure a été rejouée le 2026-10-16 sur une VM AlmaLinux 10.2 puis sur une VM Ubuntu 24.04.5, avec les mêmes fichiers : Forgejo 15.0.10, PostgreSQL 17.11, Caddy 2.11.7, Docker CE 29.9.1 et Compose v5.6.0. Vous repartez avec une instance prouvée par deux gestes : elle répond en HTTPS, et un git clone en SSH réussit.

Ce que vous allez apprendre

Choisir les briques d'une instance Forgejo de production : base, proxy, SSH.
Installer Docker sur AlmaLinux 10 et sur Ubuntu 24.04, et contourner le piège des modules noyau d'AlmaLinux.
Écrire un compose.yaml et un Caddyfile dont les images sont épinglées par digest (l'empreinte qui identifie une image à l'octet près).
Créer le premier administrateur en ligne de commande, sans passer par l'assistant web.
Vérifier l'instance par l'API, par un git clone HTTPS et par un git clone SSH.
Diagnostiquer une base injoignable et un ROOT_URL (l'adresse publique de la forge) incohérent.

Quels sont les prérequis ?

Il vous faut une VM Linux (AlmaLinux 10 ou Ubuntu 24.04, 2 vCPU et 4 Go de RAM dans le rejeu) avec un accès sudo. Le guide Installer Docker sur Linux détaille les méthodes d'installation ; ici, on suit celle du dépôt officiel de Docker. Si Compose vous est nouveau, le guide Docker Compose pose les bases du fichier utilisé plus bas.

Trois notions réseau servent tout au long de la leçon. Le DNS associe un nom à une adresse IP, voir Comprendre le DNS. TLS est le protocole qui chiffre le HTTPS : un certificat TLS prouve l'identité d'un serveur à votre client, et la CA (autorité de certification) qui l'a signé doit être connue de ce client : Générer des certificats TLS avec openssl explique la chaîne de confiance. Enfin, un reverse proxy est le serveur qui reçoit les requêtes à la place de l'application, voir Reverse proxy.

Dans le rejeu, le nom forge.lab.test est ajouté au fichier /etc/hosts de la VM. Sur votre réseau, ce nom est un enregistrement DNS qui pointe vers la machine.

Pourquoi trois conteneurs et ces ports publiés ?

Chaque brique a un rôle précis, et seuls trois ports sont ouverts. Publier un port, c'est le rendre joignable depuis la machine hôte (et au-delà) ; un port non publié reste réservé aux conteneurs du même réseau Docker. Le tableau montre ce que fait chaque conteneur et ce qu'il expose.

Brique	Rôle	Ports publiés sur la machine
Caddy (`proxy`)	termine le TLS, redirige HTTP vers HTTPS, transmet le web à Forgejo	80 et 443
Forgejo (`server`)	application web, API et serveur SSH Git	2222 vers le port 22 du conteneur
PostgreSQL (`db`)	stocke utilisateurs, dépôts déclarés, tickets	aucun

La base PostgreSQL (Forgejo 15 exige PostgreSQL 14 au minimum) remplace le SQLite que Forgejo utilise par défaut : une instance partagée par une équipe a besoin d'un vrai serveur de base, que l'on sauvegarde et que l'on surveille comme les autres (voir Installer PostgreSQL sur Linux pour l'installer hors conteneur). Le proxy TLS décharge Forgejo du chiffrement et centralise le certificat. Le guide Caddy couvre l'outil en détail.

Le SSH Git n'est pas proxifié : Caddy ne parle que HTTP. Le conteneur Forgejo publie donc son port 22 sur le 2222 de la machine, et l'adresse de clonage annoncée aux utilisateurs porte ce port. Ce choix laisse le port 22 de la machine à son propre sshd, celui de l'administration. Le port 3000, où Forgejo écoute en HTTP, reste interne au réseau Docker : un client qui l'atteindrait contournerait le proxy.

Le schéma suit les deux chemins d'un client. Le trait épais est l'entrée web : le navigateur ou git en HTTPS atteint Caddy sur les ports 80 et 443, qui transmet en HTTP au port 3000 de Forgejo, lequel interroge PostgreSQL sur le 5432. L'autre flèche est le SSH : le client parle au port 2222 de la machine, relayé vers le 22 du conteneur Forgejo, sans passer par Caddy. Seul le réseau Docker 172.30.0.0/24 voit les ports 3000 et 5432.

Source · SVG

Comment installer Docker sur AlmaLinux 10 et Ubuntu 24.04 ?

On installe Docker CE et le plugin Compose depuis le dépôt officiel de Docker, avec git, car les vérifications finales clonent des dépôts. Les deux familles de distributions n'utilisent pas le même gestionnaire de paquets, d'où deux onglets. La documentation de Docker ne cite pas AlmaLinux : elle décrit RHEL (8, 9 et 10), et l'onglet AlmaLinux emploie le dépôt rhel, que le rejeu a validé sur AlmaLinux 10.

Ubuntu 24.04
AlmaLinux 10

sudo apt-get update -qq
sudo apt-get install -y -qq ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list >/dev/null
sudo apt-get update -qq
sudo apt-get install -y -qq git docker-ce docker-ce-cli containerd.io docker-compose-plugin

sudo dnf install -y -q dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf install -y -q git docker-ce docker-ce-cli containerd.io docker-compose-plugin

Puis, sur les deux familles, on active le service et on contrôle les versions.

sudo systemctl enable --now docker
sudo docker version --format 'client {{.Client.Version}} / server {{.Server.Version}}'
sudo docker compose version

Sur Ubuntu, Docker démarre du premier coup. La sortie attendue annonce client 29.9.1 / server 29.9.1 puis la version de Compose, v5.6.0 dans le rejeu. Sur AlmaLinux, la commande systemctl enable --now docker peut échouer : c'est le piège décrit dans la section de dépannage plus bas, avec sa parade en deux commandes.

Quels fichiers écrire pour la pile ?

Trois fichiers suffisent : compose.yaml, Caddyfile et .env, tous dans /opt/forgejo-lab. Le fichier .env porte les secrets, que Compose substitue dans le compose.yaml : ils ne figurent donc jamais dans un fichier versionné. Créez le répertoire et générez les secrets.

sudo mkdir -p /opt/forgejo-lab
cd /opt/forgejo-lab
FORGE_DOMAIN=forge.lab.test
sudo install -m 600 /dev/null .env
printf 'FORGE_DOMAIN=%s\nROOT_URL=https://%s/\nPOSTGRES_PASSWORD=%s\nFORGEJO_SECRET_KEY=%s\nADMIN_PASSWORD=%s\n' \
  "$FORGE_DOMAIN" "$FORGE_DOMAIN" "$(openssl rand -hex 16)" "$(openssl rand -hex 32)" "$(openssl rand -hex 12)" \
  | sudo tee .env >/dev/null
echo "127.0.0.1 $FORGE_DOMAIN" | sudo tee -a /etc/hosts >/dev/null

Le fichier est en mode 600 : seul root le lit, ce qui est voulu, et ce qui oblige à passer par sudo pour le consulter. La dernière ligne n'existe que pour le lab : elle fait résoudre forge.lab.test vers la VM elle-même. Avec un vrai enregistrement DNS, on ne touche pas à /etc/hosts.

Voici le compose.yaml, que vous placez dans /opt/forgejo-lab. Le sous-réseau 172.30.0.0/24 et l'adresse fixe du proxy, 172.30.0.10, ont une raison précise, expliquée dans la section « Pourquoi fixer REVERSE_PROXY_TRUSTED_PROXIES ? » plus bas.

# Forgejo 15 LTS + PostgreSQL 17 + Caddy (TLS). Les secrets viennent du fichier .env.
name: forgejo-lab

networks:
  forgejo:
    ipam:
      config:
        - subnet: 172.30.0.0/24

volumes:
  forgejo-data:
  postgres-data:
  caddy-data:
  caddy-config:

services:
  db:
    image: postgres:17.11-alpine@sha256:b0f9560a2de083e2cc7382e75f808c7381a32852a7ec49117deedb300e552b24
    container_name: forgejo-db
    restart: always
    environment:
      POSTGRES_USER: forgejo
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: forgejo
    networks:
      - forgejo
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U forgejo -d forgejo"]
      interval: 5s
      timeout: 3s
      retries: 10

  server:
    image: codeberg.org/forgejo/forgejo:15.0.10@sha256:7b2f61163ff1d19f2aaf62d37ae4e805e822c2f86d6628b2bd468470929beacb
    container_name: forgejo
    restart: always
    depends_on:
      db:
        condition: service_healthy
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__database__DB_TYPE: postgres
      FORGEJO__database__HOST: db:5432
      FORGEJO__database__NAME: forgejo
      FORGEJO__database__USER: forgejo
      FORGEJO__database__PASSWD: ${POSTGRES_PASSWORD}
      FORGEJO__database__SSL_MODE: disable
      FORGEJO__server__DOMAIN: ${FORGE_DOMAIN}
      FORGEJO__server__ROOT_URL: ${ROOT_URL}
      FORGEJO__server__SSH_DOMAIN: ${FORGE_DOMAIN}
      FORGEJO__server__SSH_PORT: "2222"
      FORGEJO__security__INSTALL_LOCK: "true"
      FORGEJO__security__SECRET_KEY: ${FORGEJO_SECRET_KEY}
      FORGEJO__security__REVERSE_PROXY_TRUSTED_PROXIES: 172.30.0.10/32
      FORGEJO__service__DISABLE_REGISTRATION: "true"
    networks:
      - forgejo
    volumes:
      - forgejo-data:/data
    ports:
      # SSH Git : port 22 du conteneur publié sur 2222. Le port web 3000 n'est PAS publié.
      - "2222:22"

  proxy:
    image: caddy:2.11.7-alpine@sha256:d8542f48d34a9cf4e4c11a478865229840e87e4c96ea3f439101f31a5d35f75f
    container_name: forgejo-proxy
    restart: always
    depends_on:
      - server
    environment:
      FORGE_DOMAIN: ${FORGE_DOMAIN}
    networks:
      forgejo:
        ipv4_address: 172.30.0.10
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config

Le fichier se lit par service. Pour la base, le healthcheck appelle pg_isready toutes les 5 secondes ; Forgejo n'est lancé que lorsque la base est healthy, grâce à depends_on avec condition: service_healthy. Pour Forgejo, la convention de l'image officielle FORGEJO__section__CLE écrit chaque valeur dans la section correspondante de app.ini, le fichier de configuration de Forgejo. La variable INSTALL_LOCK à "true" saute l'assistant web d'installation : la configuration vient du fichier, pas d'un formulaire accessible à n'importe qui, et DISABLE_REGISTRATION ferme les inscriptions publiques. Les digests après le tag figent chaque image : le tag est lisible par un humain, le digest garantit l'octet près ce qui démarre.

Trois réglages d'adresse méritent une définition. ROOT_URL est l'adresse publique complète de la forge : Forgejo l'écrit dans ses liens et dans les adresses de clonage HTTPS qu'il affiche. SSH_DOMAIN et SSH_PORT jouent le même rôle pour le clonage SSH. Enfin, SSL_MODE: disable laisse la liaison avec la base en clair, ce qui reste acceptable parce qu'elle ne quitte pas le réseau Docker interne.

Le Caddyfile tient en trois lignes utiles.

# tls internal : Caddy signe avec sa propre autorité locale (certificat de test).
{$FORGE_DOMAIN} {
  tls internal
  reverse_proxy server:3000
}

Le bloc s'applique au nom lu dans la variable FORGE_DOMAIN. La directive tls internal fait signer le certificat par une CA locale créée par Caddy : c'est suffisant pour un lab, mais aucun navigateur ni aucun git ne la connaît au départ. Avec un nom public, on retire cette ligne et Caddy obtient lui-même un certificat reconnu, voir le guide Caddy. reverse_proxy server:3000 transmet les requêtes au conteneur server sur le réseau Docker ; Caddy redirige de lui-même le HTTP vers le HTTPS.

Pourquoi fixer REVERSE_PROXY_TRUSTED_PROXIES ?

Dans les images Forgejo antérieures à la version 16, ce réglage vaut * : Forgejo fait confiance à n'importe quelle machine qui lui envoie des en-têtes de proxy. La documentation de Forgejo v15 le dit dans sa note de sécurité pour les déploiements LTS : associée à un port web exposé et à [service].ENABLE_REVERSE_PROXY_AUTHENTICATION à true, cette valeur « peut avoir des conséquences dévastatrices » pour la sécurité (« devastating consequences » dans le texte anglais). Le changement est intervenu en v16.0.0, mais comme il casse la compatibilité, il n'a pas été reporté sur la branche 15 (source : documentation Docker de Forgejo v15).

La parade, que le compose.yaml applique, tient en deux gestes. Le port 3000 n'est pas publié, donc seul le réseau Docker peut l'atteindre. Et REVERSE_PROXY_TRUSTED_PROXIES est réglé sur 172.30.0.10/32, l'adresse fixe du conteneur Caddy : voilà pourquoi le réseau et l'adresse sont déclarés dans le fichier. La doc donne 127.0.0.0/8,::1/128 comme exemple pour un proxy local ; ici, le proxy est un autre conteneur, d'où son adresse. Le rejeu confirme la valeur effective dans app.ini, voir la section de vérification.

Comment démarrer la pile ?

Deux commandes, lancées depuis /opt/forgejo-lab, téléchargent les images puis démarrent les trois conteneurs. Compose lit .env et compose.yaml dans le répertoire courant.

cd /opt/forgejo-lab
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Dans le rejeu, docker compose ps montre la base healthy, puis forgejo et forgejo-proxy démarrés. Les ports publiés sont 80 et 443 (Caddy) et 2222->22 (Forgejo). Le 3000 n'apparaît pas : c'est voulu.

Comment créer le premier administrateur en ligne de commande ?

La commande forgejo admin user create --admin crée le compte dans le conteneur, sans interface web. Elle s'exécute avec l'utilisateur git du conteneur, celui qui possède les données. Le mot de passe vient du .env, que l'on charge dans le shell sans l'afficher.

cd /opt/forgejo-lab
set -a; . <(sudo cat /opt/forgejo-lab/.env); set +a
sudo docker exec -u git forgejo forgejo admin user create --admin \
  --username fjadmin --email fjadmin@example.test \
  --password "$ADMIN_PASSWORD" --must-change-password=false

La sortie attendue est New user 'fjadmin' has been successfully created!. L'option --must-change-password=false est une commodité de lab : sur une vraie instance, laissez l'administrateur changer son mot de passe à la première connexion. Pour vérifier le compte, listez les administrateurs.

sudo docker exec -u git forgejo forgejo admin user list --admin

Comment vérifier que l'instance répond en HTTPS ?

Quatre contrôles, du plus simple au plus fin, prouvent que le proxy, le TLS et le port fermé se comportent comme prévu. Le nom forge.lab.test doit se résoudre depuis la machine qui lance les commandes.

curl -s -o /dev/null -w 'code=%{http_code} ssl_verify=%{ssl_verify_result}\n' https://forge.lab.test/api/v1/version
curl -sk https://forge.lab.test/api/v1/version
curl -sI http://forge.lab.test/ | head -3
curl -s -m 3 -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/

Voici ce que le rejeu a donné, ligne par ligne :

sans -k, code=000 ssl_verify=20 : la CA de Caddy est inconnue du client, et curl refuse la connexion. C'est le comportement attendu avec tls internal ;
avec -k, {"version":"15.0.10+gitea-1.22.0"} : l'API répond, la version est celle du compose.yaml ;
en HTTP, 308 Permanent Redirect vers https://forge.lab.test/ ;
sur le port 3000, la connexion est refusée.

Enfin, regardez ce que Forgejo a réellement retenu dans app.ini.

sudo docker exec forgejo grep -E '^(ROOT_URL|DOMAIN|SSH_DOMAIN|SSH_PORT|INSTALL_LOCK|REVERSE_PROXY_TRUSTED_PROXIES|DB_TYPE|DISABLE_REGISTRATION)' /data/gitea/conf/app.ini

Le rejeu a relevé ROOT_URL = https://forge.lab.test/, SSH_PORT = 2222, DB_TYPE = postgres, INSTALL_LOCK = true, REVERSE_PROXY_TRUSTED_PROXIES = 172.30.0.10/32 et DISABLE_REGISTRATION = true. La commande sudo docker exec forgejo forgejo --version affiche 15.0.10+gitea-1.22.0.

Comment prouver le clonage en HTTPS puis en SSH ?

La preuve attendue est un git clone et un git push qui réussissent par les deux protocoles. Pour s'authentifier sans mot de passe, on crée un jeton d'accès pour fjadmin, puis un dépôt demo par l'API. Le jeton retourné par --raw est gardé dans la variable ATK.

ATK=$(sudo docker exec -u git forgejo forgejo admin user generate-access-token --username fjadmin --token-name lab-$$ --scopes all --raw)
curl -sk -H "Authorization: token $ATK" https://forge.lab.test/api/v1/user
curl -sk -H "Authorization: token $ATK" -H 'Content-Type: application/json' \
  -X POST https://forge.lab.test/api/v1/user/repos -d '{"name":"demo","auto_init":true,"default_branch":"main"}'

La réponse de l'API pour l'utilisateur confirme fjadmin avec le droit administrateur. Le dépôt créé est joignable en https://forge.lab.test/fjadmin/demo.git et en ssh://git@forge.lab.test:2222/fjadmin/demo.git.

Pour le HTTPS, git doit connaître la CA de Caddy. On copie son certificat racine depuis le conteneur du proxy, puis on le désigne avec GIT_SSL_CAINFO : c'est la vraie façon de lever l'erreur vue plus haut, sans désactiver la vérification.

W=$(mktemp -d); cd "$W"
sudo docker cp forgejo-proxy:/data/caddy/pki/authorities/local/root.crt "$W/root.crt"
sudo chown "$USER" "$W/root.crt"
export GIT_SSL_CAINFO="$W/root.crt" GIT_TERMINAL_PROMPT=0
git -c credential.helper= -c "http.extraHeader=Authorization: token $ATK" clone -q https://forge.lab.test/fjadmin/demo.git h && cd h
git config user.email a@example.test; git config user.name a
echo https > f-https.txt; git add .; git commit -qm https
git -c credential.helper= -c "http.extraHeader=Authorization: token $ATK" push -q origin main && echo push-https-ok

Le rejeu affiche push-https-ok. Pour le SSH, on génère une clé sans phrase secrète, on l'enregistre dans le compte par l'API, puis on clone sur le port 2222.

cd "$W"
ssh-keygen -q -t ed25519 -N '' -f "$W/k"
curl -sk -H "Authorization: token $ATK" -H 'Content-Type: application/json' \
  -X POST https://forge.lab.test/api/v1/user/keys -d "{\"title\":\"lab\",\"key\":\"$(cat $W/k.pub)\"}"
export GIT_SSH_COMMAND="ssh -i $W/k -p 2222 -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=ERROR"
git clone -q ssh://git@forge.lab.test:2222/fjadmin/demo.git s && echo clone-ssh-ok && cd s
git config user.email a@example.test; git config user.name a
echo ssh > f-ssh.txt; git add .; git commit -qm ssh; git push -q origin main && echo push-ssh-ok

Les options StrictHostKeyChecking=no et UserKnownHostsFile=/dev/null ne conviennent qu'à un lab jetable : elles désactivent la vérification de l'empreinte du serveur (la signature de sa clé SSH, que ssh mémorise au premier contact). Sur une vraie instance, laissez ssh enregistrer l'empreinte. Le rejeu affiche clone-ssh-ok puis push-ssh-ok, sur AlmaLinux comme sur Ubuntu : l'instance est prouvée.

Que faire quand l'installation échoue ?

Trois pannes ont été provoquées ou rencontrées pendant le rejeu, et chacune laisse une trace lisible.

Symptôme	Cause	Parade
`docker.service` échoue au démarrage sur AlmaLinux	le noyau en cours n'a pas `kernel-modules-extra`	installer le paquet du noyau en cours et recharger `iptable_nat`
Le proxy répond `502`, Forgejo est `Up`	la base est arrêtée ou injoignable	relancer la base, attendre `healthy`, redémarrer Forgejo
`clone_url` annonce `http://mauvais.test:3000/...`	`ROOT_URL` incohérent	corriger `ROOT_URL`, recréer le service `server`

Pourquoi Docker ne démarre-t-il pas sur AlmaLinux 10 ?

Le premier démarrage de docker.service échoue avec des erreurs iptables ... RULE_APPEND failed ... chain PREROUTING et failed to add jump rules to ipv4 NAT table. La cause : le noyau en marche n'a pas kernel-modules-extra, alors que dnf a installé ce paquet pour un noyau plus récent. modprobe iptable_nat répond alors Module not found, et Docker ne peut pas écrire ses règles NAT (celles qui permettent aux conteneurs de joindre l'extérieur et d'être joints par les ports publiés). La parade jouée est d'installer le paquet du noyau en cours (celui que donne uname -r), de charger le module, puis de redémarrer Docker.

sudo dnf install -y kernel-modules-extra-$(uname -r)
sudo modprobe iptable_nat
sudo systemctl restart docker
sudo docker version --format 'client {{.Client.Version}} / server {{.Server.Version}}'

La dernière commande affiche client 29.9.1 / server 29.9.1 dans le rejeu : Docker fonctionne. Ubuntu 24.04 n'a pas montré ce défaut.

Que faire quand la base est injoignable ?

Si Forgejo démarre sans pouvoir joindre PostgreSQL, il reste Up mais ne sert rien, et Caddy répond 502. Le rejeu l'a provoqué avec docker stop forgejo-db puis docker restart forgejo. Les journaux de Forgejo (sudo docker logs forgejo) montrent :

InitDBEngine() [E] ORM engine initialization attempt #1/10 failed. Error: failed to connect to user=forgejo database=forgejo: hostname resolving error: lookup db on 127.0.0.11:53: server misbehaving
Backing off for 3 seconds

Forgejo réessaie jusqu'à 10 fois (les tentatives 1/10 et 2/10 ont été observées sur AlmaLinux, jusqu'à 7/10 sur Ubuntu). Le message dit que le nom db ne se résout plus : le conteneur de la base est arrêté. La parade : relancer la base, attendre qu'elle soit healthy, puis redémarrer Forgejo.

sudo docker start forgejo-db
sudo docker restart forgejo
curl -sk https://forge.lab.test/api/v1/version

L'API répond à nouveau {"version":"15.0.10+gitea-1.22.0"}.

Que provoque un ROOT_URL incohérent ?

Avec ROOT_URL=http://mauvais.test:3000/, Forgejo démarre sans erreur, et le journal indique seulement AppURL(ROOT_URL): http://mauvais.test:3000/. Le défaut se voit ailleurs : l'API annonce clone_url = http://mauvais.test:3000/fjadmin/demo.git, alors que ssh_url reste correct, car SSH_DOMAIN et SSH_PORT sont réglés à part. Vos utilisateurs copient donc une adresse HTTP qui ne répond pas. Pour corriger, remettez la bonne valeur dans .env et recréez le service.

cd /opt/forgejo-lab
sudo sed -i 's#^ROOT_URL=.*#ROOT_URL=https://forge.lab.test/#' .env
sudo docker compose up -d server
curl -sk https://forge.lab.test/api/v1/repos/fjadmin/demo

Dans la réponse, clone_url redevient https://forge.lab.test/fjadmin/demo.git. Le rejeu n'a pas pu conclure sur un éventuel blocage de la connexion par le navigateur avec ce mauvais ROOT_URL : seul le défaut de clone_url est établi.

Comment nettoyer le lab ?

Un seul enchaînement supprime les conteneurs, les volumes, les fichiers et l'entrée /etc/hosts, et laisse Docker installé. L'option -v de docker compose down détruit aussi les volumes : vos dépôts de test disparaissent avec. Sur une instance que vous gardez, ne lancez pas cette commande.

cd /opt/forgejo-lab && sudo docker compose down -v --remove-orphans
sudo docker ps -a --format '{{.Names}}'; sudo docker volume ls -q
cd / && sudo find /opt/forgejo-lab -delete
sudo sed -i '/forge.lab.test/d' /etc/hosts

Le rejeu retire trois conteneurs, quatre volumes et un réseau ; les deux commandes de contrôle ne listent plus rien. Pour conserver les données d'une vraie instance, voir Sauvegarder et restaurer Forgejo. Courrier, stockage, LFS et réglages d'inscription se règlent après l'installation, dans Configuration initiale de Forgejo.

À retenir

Une instance Forgejo de production se compose de trois briques : Forgejo, PostgreSQL et un proxy TLS (Caddy ici), déployées par un seul compose.yaml.
Le SSH Git n'est pas proxifié : le port 22 du conteneur est publié sur le 2222, et SSH_PORT annonce ce port aux utilisateurs.
Le port web 3000 n'est pas publié et REVERSE_PROXY_TRUSTED_PROXIES est fixé à l'adresse du proxy : en v15, la valeur par défaut des images est * (documentation Forgejo v15).
INSTALL_LOCK saute l'assistant web, et le premier administrateur se crée avec forgejo admin user create --admin.
Les images sont épinglées par digest : 15.0.10, 17.11-alpine et 2.11.7-alpine ne bougent pas au redémarrage.
Sur AlmaLinux 10, un Docker qui ne démarre pas peut venir de kernel-modules-extra absent du noyau en cours.
La preuve de l'installation : HTTPS qui répond (/api/v1/version, redirection 308), puis git clone et git push réussis en HTTPS et en SSH.
ROOT_URL mal réglé ne produit aucune erreur au démarrage : on le détecte au clone_url de l'API.