Installer GlitchTip sur un VPS : le tracker d'erreurs souverain

Pourquoi migrer vers GlitchTip maintenant

Sentry self-hosted 26.4.x souffre depuis août 2026 de cinq régressions simultanées documentées par la communauté. Les issues #4301 et #4306 décrivent respectivement des consumers Snuba qui redémarrent en boucle sans traiter d'événements, et un deadlock dans le monitor_consumer qui bloque l'enregistrement des crons. L'issue #4321 signale un échec d'authentification du relay sur les connexions HTTP/2, ce qui interrompt l'ingestion des événements. Ces régressions ont poussé plusieurs équipes à documenter publiquement leur migration vers GlitchTip.

L'objection la plus fréquente est la compatibilité : vous avez instrumenté vos applications avec le SDK Sentry (sentry-python, @sentry/node, sentry-rails…) et vous ne souhaitez pas réécrire cette instrumentation. GlitchTip implémente l'API Sentry et accepte les événements envoyés par ces mêmes SDK. Le swap se résume à remplacer la valeur de votre variable d'environnement SENTRY_DSN par le DSN que GlitchTip vous fournit lors de la création du projet. Zéro modification de code applicatif.

Ce que vous obtenez avec GlitchTip v6 auto-hébergé

Empreinte réduite — quatre conteneurs seulement (Django, Celery, PostgreSQL, Redis), contre la vingtaine de services de Sentry self-hosted.
Compatibilité SDK Sentry — tous les SDK Sentry officiels fonctionnent sans modification ; seul le DSN change.
Souveraineté des données — les traces d'erreurs et les données utilisateur restent sur votre infrastructure, sous votre politique de rétention.
Licence GPL-3.0 — le code est auditable, sans composant propriétaire ni fonctionnalité réservée à un plan payant.
Monitoring de disponibilité — GlitchTip inclut des monitors de type uptime (ping HTTP) sans dépendance externe.
Interface de gestion des performances — suivi des transactions, des traces N+1 et des requêtes lentes via l'API Sentry compatible.
Faible consommation de RAM — 2 Go de RAM suffisent pour un usage solo ou petite équipe, sans ajustement de configuration.

Prérequis avant de démarrer

GlitchTip v6 repose sur quatre conteneurs : Django (le serveur web et l'interface), Celery (les tâches asynchrones de traitement d'événements), PostgreSQL (la base de données principale) et Redis (la file de tâches). Il vous faut :

- Un VPS Linux avec 2 Go de RAM minimum (4 Go sont confortables pour une équipe de dix développeurs et un volume de quelques centaines d'erreurs par jour).
- Docker et Docker Compose installés — disponibles sur toutes les distributions récentes.
- Un nom de domaine ou sous-domaine pointé vers l'adresse IP de votre VPS, pour activer HTTPS via Let's Encrypt.
- Les ports 80 et 443 ouverts dans votre pare-feu.

Sur un VPS ServOrbit, Docker est préinstallé. Les offres à partir de 2 vCPU et 2 Go de RAM couvrent exactement ce profil de charge.

Déployer GlitchTip avec Docker Compose

Créer le répertoire de travail

Connectez-vous à votre VPS en SSH, puis créez un répertoire dédié :

mkdir -p /opt/glitchtip && cd /opt/glitchtip

Créer le fichier de variables d'environnement

Créez un fichier .env avec les valeurs de configuration :

SECRET_KEY=<chaîne-aléatoire-longue> — générez-la avec openssl rand -hex 32.
DATABASE_URL=postgresql://glitchtip:motdepasse@db:5432/glitchtip
REDIS_URL=redis://redis:6379/0
GLITCHTIP_DOMAIN=https://glitchtip.votre-domaine.com
[email protected]
EMAIL_URL=smtp://utilisateur:[email protected]:587

Remplacez les valeurs par vos propres identifiants. Le champ GLITCHTIP_DOMAIN doit correspondre exactement au domaine que vous allez sécuriser avec HTTPS — il est inscrit dans les DSN générés.

Créer le fichier docker-compose.yml

Créez un fichier docker-compose.yml avec le contenu suivant (adapté depuis la documentation officielle GlitchTip) :

version: "3.8"
x-environment: &default-environment
  env_file: .env
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: glitchtip
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: motdepasse
    volumes:
      - pg_data:/var/lib/postgresql/data
  redis:
    image: redis:7
    volumes:
      - redis_data:/data
  web:
    image: glitchtip/glitchtip:latest
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8000:8080"
    <<: *default-environment
  worker:
    image: glitchtip/glitchtip:latest
    command: ./bin/run-celery-with-beat.sh
    depends_on: [db, redis]
    <<: *default-environment
volumes:
  pg_data:
  redis_data:

Notez que le port 8000 est lié à 127.0.0.1 uniquement : le service ne sera jamais exposé directement, mais via un proxy inverse.

Initialiser la base de données

Lancez les migrations Django pour créer le schéma :

docker compose run --rm web ./manage.py migrate

Cette commande est à lancer une seule fois à l'installation, puis lors de chaque mise à jour vers une nouvelle version de GlitchTip.

Créer le premier super-utilisateur

Créez votre compte administrateur :

docker compose run --rm web ./manage.py createsuperuser

Saisissez l'adresse e-mail et le mot de passe lorsque l'assistant les demande.

Démarrer la stack

Démarrez tous les conteneurs en arrière-plan :

docker compose up -d

Vérifiez que les quatre conteneurs sont en cours d'exécution avec docker compose ps. Le service web répond sur http://127.0.0.1:8000.

Configurer le proxy inverse nginx avec HTTPS

Installez nginx et Certbot si ce n'est pas déjà fait :

apt install -y nginx certbot python3-certbot-nginx

Créez un vhost dans /etc/nginx/sites-available/glitchtip avec le bloc server qui écoute sur le port 80, définit server_name glitchtip.votre-domaine.com et transmet le trafic vers http://127.0.0.1:8000 avec proxy_pass. Activez la configuration, puis obtenez le certificat :

certbot --nginx -d glitchtip.votre-domaine.com

Certbot met à jour automatiquement le vhost pour rediriger HTTP vers HTTPS et ajoute le bloc SSL.

Brancher le SDK Sentry de vos applications

Dans l'interface GlitchTip, créez une organisation, puis un projet. GlitchTip génère un DSN du format https://<clé>@glitchtip.votre-domaine.com/<id-projet>.

Dans chacune de vos applications, remplacez la valeur de SENTRY_DSN (ou du paramètre dsn passé à Sentry.init()) par ce nouveau DSN. Redémarrez vos processus. Les événements apparaissent dans GlitchTip sans aucune autre modification.

Configuration post-installation

Après le premier démarrage, ajustez ces points dans l'interface d'administration :

Variables d'environnement complémentaires. Activez l'envoi d'alertes par e-mail en définissant EMAIL_URL dans votre .env. Ajoutez GLITCHTIP_MAX_EVENT_LIFE_DAYS=90 pour limiter la rétention des événements et maîtriser la croissance de la base de données.

Accès multi-équipes. GlitchTip gère des organisations et des membres avec différents niveaux de permission. Créez vos équipes depuis Paramètres → Membres et invitez vos développeurs par e-mail.

Monitors de disponibilité. Dans la section Monitors de votre projet, créez un monitor de type ping pour chacun de vos services exposés : GlitchTip envoie une requête HTTP à intervalle régulier et crée une issue si le service ne répond pas dans le délai configuré.

Durcissement de la stack

Restreignez l'accès au port 8000 avec ufw : ufw allow 80/tcp && ufw allow 443/tcp && ufw deny 8000/tcp. Ajoutez SECURE_SSL_REDIRECT=True et SESSION_COOKIE_SECURE=True dans votre .env pour forcer HTTPS au niveau Django. Planifiez un pg_dump quotidien vers un emplacement distant — le volume pg_data contient l'intégralité de vos données d'erreurs et de configuration. Enfin, consultez le guide de durcissement initial d'un serveur Linux avant d'exposer l'instance à la production.

Dépannage des erreurs courantes

Error: relation "glitchtip_*" does not exist — La migration n'a pas été jouée. Exécutez docker compose run --rm web ./manage.py migrate et vérifiez que le conteneur db est en bonne santé avec docker compose ps.

CSRF verification failed. Request aborted. — La variable GLITCHTIP_DOMAIN ne correspond pas au domaine depuis lequel vous accédez à l'interface. Vérifiez qu'elle est définie sans barre oblique finale et relancez les conteneurs avec docker compose restart.

Connection refused sur le DSN depuis votre application — Le port 8000 n'est pas accessible depuis l'extérieur (c'est voulu). Vérifiez que nginx transmet correctement le trafic HTTPS vers 127.0.0.1:8000 : curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8000/api/0/ doit renvoyer 200.

Les événements apparaissent dans les logs Celery mais pas dans l'interface — Le worker Celery a démarré avant que les migrations soient terminées. Relancez-le avec docker compose restart worker.

No such file or directory: '/etc/nginx/sites-enabled/glitchtip' — Vous avez oublié de créer le lien symbolique. Exécutez ln -s /etc/nginx/sites-available/glitchtip /etc/nginx/sites-enabled/ puis nginx -t && systemctl reload nginx.

GlitchTip en production sur un VPS

GlitchTip v6, publié en février 2026 sous licence GPL-3.0, repose sur quatre conteneurs. Sa compatibilité avec le SDK Sentry en fait une sortie propre de Sentry self-hosted lorsque celui-ci accumule des régressions difficiles à contourner.

Pour aller plus loin, consultez notre guide sur la checklist Docker Compose en production pour sécuriser davantage votre déploiement, et notre article sur la routine de correctifs des apps self-hosted pour maintenir GlitchTip à jour sans interruption de service.

Une instance GlitchTip tient dans 2 Go de RAM : un VPS à 2 vCPU et 2 Go de RAM couvre exactement ce profil, avec accès root et choix de l'OS.