Quelle quantité de RAM Gitea nécessite-t-il ?

Gitea utilise environ 100–150 Mo de RAM au repos avec SQLite, ce qui en fait l'une des forges Git les plus légères disponibles. PostgreSQL ajoute environ 30–50 Mo supplémentaires.

Quelle est la différence entre Gitea et Forgejo ?

Forgejo est un fork doux de Gitea créé en 2022 suite à des préoccupations de gouvernance. Il reste compatible en API avec Gitea mais livre certaines fonctionnalités plus rapidement et a un modèle de gouvernance communautaire.

Gitea supporte-t-il les workflows GitHub Actions ?

Oui. Gitea Actions utilise la même syntaxe YAML que GitHub Actions et s'exécute via act_runner. La plupart des fichiers de workflow fonctionnent sans modification.

Gitea peut-il mettre en miroir des dépôts depuis GitHub ou GitLab ?

Oui. Gitea supporte le mirroring push et pull depuis GitHub, GitLab, Bitbucket et tout remote Git. Les mirrors pull se synchronisent automatiquement selon un intervalle configurable.

Gitea : Guide Complet de Forge Git Auto-hébergée et Alternative à GitHub

TL;DR — Résumé Rapide

Déployez Gitea comme forge Git auto-hébergée. Couvre Docker Compose, Gitea Actions, LDAP, OAuth2, registres de paquets, mirroring et proxy inverse Caddy.

Gitea est une forge Git légère et auto-hébergée écrite en Go, distribuée sous forme d’un binaire unique capable de fonctionner confortablement sur du matériel aussi modeste qu’un Raspberry Pi. Si vous avez toujours voulu un contrôle total sur votre code source, vos pipelines CI/CD, votre suivi des issues et vos registres de paquets sans payer les tarifs du cloud GitHub ou GitLab — et sans le poids opérationnel d’une instance GitLab CE — Gitea est la réponse. Ce guide couvre tout, depuis un déploiement de production avec Docker Compose jusqu’à Gitea Actions CI, SSO OAuth2, registres de paquets et mirroring de dépôts.

Prérequis

Docker et Docker Compose v2 installés sur l’hôte
Un nom de domaine pointant vers le serveur (pour le TLS avec Caddy)
Au moins 512 Mo de RAM et 2 Go de disque (Gitea lui-même a besoin de ~150 Mo)
Familiarité de base avec les volumes Docker et la syntaxe YAML
Port 3000 (ou 80/443 via proxy inverse) accessible depuis votre réseau

Architecture de Gitea

Gitea est une application Go compilée en un seul binaire sans dépendances d’exécution. Il intègre un serveur web, des hooks Git, un daemon SSH et des workers en arrière-plan. Options de stockage :

Backend	Idéal pour	Notes
SQLite	Utilisateur seul / petites équipes	Zéro config ; inadapté à la haute concurrence
PostgreSQL	Équipes et production	Recommandé ; meilleures performances
MySQL / MariaDB	Infrastructure MySQL existante	Supporté ; PostgreSQL préféré

Gitea vs Forgejo vs Alternatives

Forge	Langage	RAM (idle)	Actions CI	Registre de paquets	Licence
Gitea	Go	~120 Mo	Oui (act_runner)	Oui (11 types)	MIT
Forgejo	Go	~120 Mo	Oui (act_runner)	Oui	MIT
GitLab CE	Ruby/Go	~2–4 Go	Oui (natif)	Oui	MIT
Gogs	Go	~50 Mo	Non	Non	MIT
OneDev	Java	~500 Mo	Oui	Limité	MIT
Sourcehut	Python/Go	~100 Mo	Oui (builds.sr.ht)	Non	AGPL

Forgejo est compatible en API avec Gitea et les runners sont interchangeables. GitLab CE est beaucoup plus riche en fonctionnalités, mais nécessite 10 à 20 fois plus de ressources.

Étape 1 : Déployer avec Docker Compose et PostgreSQL

Créez un répertoire de projet et un docker-compose.yml :

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=changeme
    volumes:
      - gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    container_name: gitea-db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=changeme
      - POSTGRES_DB=gitea
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  gitea-data:
  postgres-data:

docker compose up -d

Ouvrez http://votre-serveur:3000 dans un navigateur. L’installateur web pré-remplit les paramètres de la base de données depuis les variables d’environnement. Configurez simplement l’URL de base, le nom d’utilisateur administrateur, l’e-mail administrateur et le mot de passe administrateur, puis cliquez sur Installer.

Étape 2 : Configurer app.ini

Après l’installation, app.ini se trouve dans le volume Docker sous gitea/conf/app.ini :

[server]
DOMAIN           = git.exemple.com
ROOT_URL         = https://git.exemple.com/
HTTP_PORT        = 3000
SSH_DOMAIN       = git.exemple.com
SSH_PORT         = 22
SSH_LISTEN_PORT  = 22
DISABLE_SSH      = false
LFS_START_SERVER = true

[repository]
DEFAULT_BRANCH          = main
ENABLE_PUSH_CREATE_USER = false
DEFAULT_PRIVATE         = private

[security]
INSTALL_LOCK              = true
SECRET_KEY                = <générer-avec-openssl-rand-hex-32>
INTERNAL_TOKEN            = <générer-avec-gitea-generate-secret>
MIN_PASSWORD_LENGTH       = 12
PASSWORD_COMPLEXITY       = lower,upper,digit,spec

[service]
DISABLE_REGISTRATION              = false
REQUIRE_SIGNIN_VIEW               = false
REGISTER_EMAIL_CONFIRM            = true
ENABLE_NOTIFY_MAIL                = true

[mailer]
ENABLED   = true
SMTP_ADDR = smtp.exemple.com
SMTP_PORT = 587
FROM      = "Gitea <gitea@exemple.com>"
USER      = gitea@exemple.com
PASSWD    = `votre-mot-de-passe-smtp`

Redémarrez pour appliquer :

docker compose restart gitea

Étape 3 : Gestion des Dépôts

Git LFS

LFS est activé avec LFS_START_SERVER = true dans [server]. Les utilisateurs configurent leur client local une fois :

git lfs install
git lfs track "*.psd" "*.zip" "*.tar.gz"

Mirroring de Dépôts

Les mirrors pull permettent à Gitea de cloner et synchroniser périodiquement depuis GitHub, GitLab ou tout remote Git. Dans l’interface web : Nouveau Dépôt → Migrer. Cochez Ce dépôt sera un mirror avec l’intervalle de synchronisation souhaité.

Les mirrors push envoient chaque commit vers un remote automatiquement. Configurez dans Paramètres du dépôt → Paramètres de mirror → Push Mirrors.

Branches Protégées et Stratégies de Fusion

Dans Paramètres du dépôt → Branches → Ajouter une règle de protection de branche :

Exiger des révisions de pull request — définissez les approbations minimales
Exiger des vérifications de statut — bloque la fusion si le workflow Actions échoue
Stratégies de fusion — activez/désactivez merge commit, squash et rebase par dépôt

Étape 4 : Gitea Actions CI

Gitea Actions est le système CI intégré utilisant la même syntaxe YAML que GitHub Actions.

Enregistrer un act_runner

Téléchargez le dernier binaire act_runner depuis https://gitea.com/gitea/act_runner/releases. Dans le panneau d’administration, allez dans Administration du site → Actions → Runners → Créer un nouveau token de runner.

# Enregistrer le runner
act_runner register \
  --instance https://git.exemple.com \
  --token <token-runner> \
  --name mon-runner \
  --labels ubuntu-latest:docker://node:20-bullseye

# Démarrer comme service
act_runner daemon

Exemple de Workflow

# .gitea/workflows/build.yml
name: Compiler et Tester

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"
      - run: npm ci
      - run: npm test

  docker:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Construire l'image Docker
        run: docker build -t monapp:${{ gitea.sha }} .
      - name: Publier dans le registre Gitea
        run: |
          docker login git.exemple.com -u ${{ secrets.REGISTRY_USER }} -p ${{ secrets.REGISTRY_TOKEN }}
          docker push git.exemple.com/monorg/monapp:${{ gitea.sha }}

Étape 5 : Gestion des Utilisateurs et Authentification

Comptes Locaux et 2FA

2FA via TOTP disponible dans Paramètres utilisateur → Sécurité → Authentification à deux facteurs.

LDAP / Active Directory

Administration du site → Identité et accès → Sources d’authentification → LDAP (via BindDN) :

Hôte : ldap.exemple.com
Port : 389 (ou 636 pour LDAPS)
DN de liaison : cn=gitea,ou=comptes-service,dc=exemple,dc=com
Base de recherche d’utilisateurs : ou=utilisateurs,dc=exemple,dc=com
Filtre d’utilisateur : (&(objectClass=person)(sAMAccountName=%s))

Fournisseurs OAuth2

Fournisseur	Source du Client ID	Portée
GitHub	github.com/settings/developers	`read:user,user:email`
GitLab	gitlab.com/-/profile/applications	`read_user`
Google	console.cloud.google.com	`openid email profile`

Étape 6 : Proxy Inverse Caddy avec TLS

Ajoutez ceci dans votre Caddyfile :

git.exemple.com {
    reverse_proxy gitea:3000

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Frame-Options "SAMEORIGIN"
        X-Content-Type-Options "nosniff"
    }
}

Caddy récupère automatiquement les certificats Let’s Encrypt à la première requête vers le domaine.

Organisations, Équipes et Permissions

Rôle	Dépôts	Panneau admin	Créer des dépôts
Propriétaire	Tous dans l’org	Oui	Oui
Admin (équipe)	Dépôts de l’équipe	Non	Périmètre équipe
Écriture (équipe)	Dépôts de l’équipe	Non	Non
Lecture (équipe)	Dépôts de l’équipe	Non	Non

Registre de Paquets Gitea

Activez le registre de paquets dans app.ini :

[packages]
ENABLED = true

Types de paquets supportés : npm, PyPI, Maven, NuGet, Docker/OCI, Composer, Cargo, Conan, Helm, RubyGems et APT Alpine/Debian.

Sauvegarde et Restauration

# Dans le conteneur
docker exec -u git gitea gitea dump -c /data/gitea/conf/app.ini \
  -t /tmp --type tar.gz

# Copier l'archive vers l'hôte
docker cp gitea:/tmp/gitea-dump-*.tar.gz ./sauvegardes/

Migration depuis GitHub, GitLab ou Gogs

Administration du site → Migrations supporte l’importation complète en préservant les issues, pull requests, labels, jalons, releases et pages wiki. La migration de Gogs vers Gitea est transparente — Gitea lit directement la base de données de Gogs.

Pièges et Cas Particuliers

Conflit de port SSH — Si le port 22 est déjà utilisé par le daemon SSH de l’hôte, mappez le SSH de Gitea sur un port différent (ex. : 222:22) et mettez à jour SSH_PORT dans app.ini.

Docker-in-Docker avec act_runner — Pour les workflows qui construisent des images Docker, le runner a besoin d’accès au socket Docker. Montez /var/run/docker.sock dans le conteneur du runner.

Croissance du stockage LFS — Les objets LFS ne sont pas collectés automatiquement. Planifiez gitea admin repo-lfs-prune périodiquement.

Dépannage

Problème	Solution
L’interface web retourne 502	Vérifiez `docker logs gitea` ; confirmez les variables d’environnement de connexion BD
Le clone SSH échoue	Confirmez que SSH_PORT correspond au mapping de port de l’hôte
Workflow Actions en attente indéfiniment	Vérifiez que act_runner est en cours d’exécution et enregistré ; vérifiez les labels
Push de paquet avec erreur 401	Générez un token avec portée `package` ; utilisez-le comme mot de passe du registre
Le mirror ne se synchronise pas	Vérifiez que l’URL du mirror est accessible depuis le conteneur

Résumé

Gitea fonctionne avec ~120 Mo de RAM comme binaire Go unique — bien plus léger que GitLab CE
Docker Compose avec PostgreSQL est le déploiement de production recommandé
app.ini contrôle chaque aspect : sécurité, mailer, LFS, paquets et SSH
Gitea Actions utilise la syntaxe YAML de GitHub Actions ; act_runner exécute les jobs dans des conteneurs Docker
LDAP, OAuth2 (GitHub/GitLab/Google) et TOTP 2FA sont intégrés nativement
Les registres de paquets supportent npm, PyPI, Maven, NuGet, Docker/OCI et plus
Le mirroring de dépôts (push et pull) garde les dépôts externes synchronisés automatiquement

Gitea : Guide Complet de Forge Git Auto-hébergée et Alternative à GitHub

Prérequis

Architecture de Gitea

Gitea vs Forgejo vs Alternatives

Étape 1 : Déployer avec Docker Compose et PostgreSQL

Étape 2 : Configurer app.ini

Étape 3 : Gestion des Dépôts

Git LFS

Mirroring de Dépôts

Branches Protégées et Stratégies de Fusion

Étape 4 : Gitea Actions CI

Enregistrer un act_runner

Exemple de Workflow

Étape 5 : Gestion des Utilisateurs et Authentification

Comptes Locaux et 2FA

LDAP / Active Directory

Fournisseurs OAuth2

Étape 6 : Proxy Inverse Caddy avec TLS

Organisations, Équipes et Permissions

Registre de Paquets Gitea

Sauvegarde et Restauration

Migration depuis GitHub, GitLab ou Gogs

Pièges et Cas Particuliers

Dépannage

Résumé

Articles Connexes

Frequently Asked Questions

Prérequis

Architecture de Gitea

Gitea vs Forgejo vs Alternatives

Étape 1 : Déployer avec Docker Compose et PostgreSQL

Étape 2 : Configurer app.ini

Étape 3 : Gestion des Dépôts

Git LFS

Mirroring de Dépôts

Branches Protégées et Stratégies de Fusion

Étape 4 : Gitea Actions CI

Enregistrer un act_runner

Exemple de Workflow

Étape 5 : Gestion des Utilisateurs et Authentification

Comptes Locaux et 2FA

LDAP / Active Directory

Fournisseurs OAuth2

Étape 6 : Proxy Inverse Caddy avec TLS

Organisations, Équipes et Permissions

Registre de Paquets Gitea

Sauvegarde et Restauration

Migration depuis GitHub, GitLab ou Gogs

Pièges et Cas Particuliers

Dépannage

Résumé

Articles Connexes

Frequently Asked Questions

Articles Connexes

Woodpecker CI : CI/CD Auto-Hébergé et Léger avec Gitea

MinIO : Guide Complet du Stockage Objet Auto-Hébergé Compatible S3

Gitea : Serveur Git Auto-Hébergé — Installation, Migration et Dépannage