Alternatives à Sentry auto-hébergé : RAM et coûts

Le coût du suivi des erreurs auto-hébergé avant le stockage du premier événement

Le suivi des erreurs auto-hébergé repose sur un facteur déterminant : la quantité minimale de RAM. La documentation officielle de Sentry pour l’auto-hébergement demande 4 cœurs CPU, 16 GB de RAM, 16 GB de swap et 20 GB d’espace disque libre, avant même que votre application n’envoie un seul événement. GlitchTip documente 512 MB. Toutes les solutions présentées ici acceptent les événements provenant des mêmes SDK Sentry. Le choix ne concerne donc pas l’instrumentation de votre code. Il dépend de la taille du serveur que vous êtes prêt à financer et à maintenir en fonctionnement.

Ressources publiées par les projets, côte à côte

Voici les chiffres que chaque projet publie à son sujet, en août 2026. Ils ne correspondent pas au même type de mesure. Lisez donc la note de chaque ligne avant de les comparer.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Les 16 Go de Sentry correspondent à un minimum documenté, et la même page recommande 32 Go. Les 0.5 Go de GlitchTip correspondent à une recommandation. Le projet indique 256 Mo comme minimum fonctionnel, ou 128 Mo avec du swap et une configuration soigneuse. Les 4 Go de Bugsink ne correspondent à aucun de ces deux cas : il s’agit de la machine utilisée par l’éditeur pour son propre benchmark de débit. Une valeur publiée constitue un point de départ, pas une garantie adaptée au volume de vos événements.

Sentry auto-hébergé : le produit complet, et la facture complète

La stack officielle est getsentry/self-hosted, un projet Docker Compose qui exécute les mêmes composants que ceux utilisés par Sentry en production. Sa documentation la décrit comme « complète sur le plan fonctionnel et empaquetée pour les déploiements à faible volume et les preuves de concept ». Cette phrase résume honnêtement la situation. Vous obtenez toutes les fonctionnalités, ainsi que tous les composants nécessaires à leur fonctionnement.

Installez une release marquée plutôt que depuis master :

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

Démarrez ensuite la stack :

docker compose up --wait

Sentry écoute par défaut sur http://127.0.0.1:9000. Docker Engine 19.03.6 ou une version ultérieure et Docker Compose 2.32.2 ou une version ultérieure sont requis. Une ancienne version de Compose échoue à cause de la syntaxe du fichier, et non à cause de Sentry.

Vérifiez ce qui a réellement démarré :

docker compose ps
free -h

docker compose ps répertorie tous les services de la stack, et la liste est longue : Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, ainsi que plusieurs processus de worker et de cron. Comptez-les une fois, car ce nombre correspond à votre charge de maintenance. Chaque entrée représente un processus qui peut s’arrêter, remplir un disque ou échouer lors d’une migration.

Si un service reste dans l’état Restarting, vérifiez d’abord la mémoire :

dmesg -T | grep -i 'out of memory'

Une ligne comme Out of memory: Killed process 3412 (java) signifie que l’OOM killer du noyau (out of memory killer) a arrêté un conteneur parce que la machine n’avait plus assez de RAM. Le service ne devient donc jamais healthy et la stack ne finit jamais de démarrer. C’est le résultat habituel de l’exécution de la stack complète avec le minimum de ressources indiqué dans la documentation. La documentation signale également la vitesse du disque : iowait au-dessus de 10% signifie que la machine ne suit pas le pipeline d’ingestion. Consultez cette valeur dans la colonne wa de top, ou dans iostat -x 5 si sysstat est installé.

Les mises à niveau sont la partie que l’on sous-estime

Sentry auto-hébergé publie une release chaque mois selon CalVer, un schéma de version fondé sur le calendrier, avec une release principale le 15 de chaque mois. Vous ne pouvez pas passer directement d’une ancienne version à la dernière. Le projet définit des versions d’arrêt obligatoires, et vous devez faire un checkout de chacune d’elles dans l’ordre pour appliquer leurs migrations de base de données. En août 2026, les versions d’arrêt publiées sont 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 et 26.7.0. La documentation répertorie également les releases à éviter à cause de problèmes de migration, notamment 23.7.0, 25.9.0, 25.12.0 et la plage allant de 26.3.0 à 26.4.0.

Une mise à niveau consiste à faire un checkout, puis à relancer l’installateur :

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

Faites un snapshot du serveur avant de commencer, car une migration sur un gros dataset ClickHouse peut durer plusieurs heures. En cas d’échec en cours de route, la base de données reste entre deux schémas. La cause la plus fréquente des échecs de mise à niveau de Sentry auto-hébergé est simple : la machine est restée sur une version pendant un an. La mise à niveau franchit donc plusieurs versions d’arrêt à la fois, et l’une des migrations à éviter était précisément celle qui comptait.

Vous devez également connaître un dernier point avant de vous engager. Sentry auto-hébergé est distribué sous la Functional Source License (FSL), introduite par Sentry. Il s’agit d’un logiciel à source disponible, et non d’un logiciel open source approuvé par l’OSI : vous pouvez l’exécuter pour votre propre usage, mais vous ne pouvez pas le vendre comme un service concurrent. Chaque release est convertie sous Apache 2.0 deux ans après sa publication.

GlitchTip : la réponse tient dans 512 MB

GlitchTip est distribué sous licence MIT et reçoit les événements des SDK open source de Sentry. Une application instrumentée peut donc être transférée en modifiant une seule valeur : le DSN (data source name, l’URL vers laquelle votre SDK envoie les événements). GlitchTip nécessite PostgreSQL 14 ou une version ultérieure. Valkey ou Redis 7 ou une version ultérieure est facultatif, mais accélère les instances plus importantes.

L’installation se résume à Docker et à un fichier compose :

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Modifiez la section d’environnement avant de démarrer quoi que ce soit. Vous devez définir le secret, le domaine et le chemin de messagerie :

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

L’exemple relie déjà DATABASE_URL à son propre service postgres. Ne modifiez donc pas cette ligne, sauf si vous utilisez une base de données exécutée ailleurs. GLITCHTIP_DOMAIN doit inclure le schéma. Sans https:// au début, les liens des e-mails d’alerte sont mal construits et renvoient vers une URL qui ne répond pas.

Démarrez le service et surveillez le premier démarrage :

docker compose up -d
docker compose logs -f web

Dans l’exemple, les tags d’image en date d’août 2026 sont postgres:18, valkey/valkey:9 et glitchtip/glitchtip:6. Conservez-les en les épinglant. Un fichier compose contenant latest mettra à niveau votre moteur de base de données lors du prochain docker compose pull. Une montée de version majeure de Postgres sur une instance en fonctionnement peut empêcher un outil de suivi des erreurs fonctionnel de redémarrer.

Pour atteindre la plage de 256 MB à 512 MB, les commentaires du fichier d’exemple indiquent les composants à désactiver, en commençant par Valkey et par les fonctions facultatives de journalisation et de suivi de disponibilité. Sans Valkey, GlitchTip utilise sa base de données pour le cache et les files d’attente. Le fonctionnement est plus lent, mais reste correct. Le mode tout-en-un exécute le worker dans le processus web. Vous ne gérez donc qu’un seul conteneur applicatif au lieu de deux.

Placez un proxy devant le service. La documentation de GlitchTip demande un proxy ou un load balancer qui met les requêtes en tampon et gère le Transfer-Encoding en segments. Elle utilise nginx comme exemple détaillé. Sans mise en tampon, un client lent maintient un worker applicatif ouvert pendant toute la durée de l’envoi. Quelques émetteurs lents peuvent donc occuper tous les workers disponibles et les clients en bonne santé commencent à subir des timeouts.

Les mises à niveau sont la partie la plus simple :

docker compose pull
docker compose stop
docker compose up -d

Les migrations de base de données s’exécutent automatiquement au démarrage. Effectuez tout de même un dump au préalable, car une migration automatique reste une migration.

Bugsink : un conteneur et une licence à lire attentivement

Bugsink est le plus léger des trois. Il parle le protocole Sentry SDK et fonctionne sans file de messages ni service externe autre qu’une base de données. SQLite est utilisé par défaut. MySQL et PostgreSQL sont pris en charge lorsque SQLite ne suffit plus.

Pour tester l’interface avant de vous engager, lancez une instance temporaire :

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Ouvrez http://localhost:8000/, puis connectez-vous avec l’adresse et le mot de passe indiqués dans CREATE_SUPERUSER. Ce conteneur ne conserve rien lorsqu’il s’arrête. Pour une véritable instance, utilisez l’exemple de compose du projet. Il associe bugsink/bugsink:2 à postgres:17-alpine et définit DATABASE_URL, BASE_URL et BEHIND_HTTPS_PROXY. Générez correctement le secret :

openssl rand -base64 50

BASE_URL doit correspondre à l’URL réellement utilisée par vos utilisateurs et vos SDK, schéma inclus. Laissez cette valeur à http://localhost:8000 sur un serveur accessible à l’adresse https://errors.example.com et chaque lien d’un e-mail de notification pointera vers un hôte que son destinataire ne pourra pas résoudre. Définissez BEHIND_HTTPS_PROXY sur true lorsque nginx ou Caddy termine TLS (Transport Layer Security) en amont, car Bugsink génère sinon des URL http:// derrière votre proxy https:// et les navigateurs bloquent le contenu mixte.

L’éditeur publie ses propres mesures de débit : 18 événements par seconde de 50 KB chacun, soit 1.5 million d’événements par jour, sur un VPS doté de 2 vCPU et de 4 GB de mémoire. Considérez ces chiffres comme une indication des capacités de l’outil, et non comme une garantie pour votre charge. Ils montrent néanmoins que la limite se situe largement au-dessus de ce que produit une petite application.

Reste la licence. C’est le point à lire avant d’intégrer Bugsink à votre stack. Bugsink est distribué sous la licence PolyForm Shield License 1.0.0. Le code est disponible, mais le logiciel n’est pas open source : vous pouvez l’exécuter et le modifier, mais vous ne pouvez pas l’utiliser pour créer un produit concurrent de Bugsink. Cette restriction ne pose généralement pas de problème pour un outil interne de suivi des erreurs. Si votre entreprise vend des outils pour développeurs, faites d’abord lire le texte de la licence.

Le suivi des erreurs et l’observabilité des LLM restent deux outils distincts

Recherchez un outil qui assure à la fois le suivi des erreurs et l’observabilité des grands modèles de langage (LLM) : vous trouverez des produits qui revendiquent ces deux fonctions. Les structures de données sont différentes, ce qui explique pourquoi cette fusion ne se concrétise pas. Un outil de suivi des erreurs reçoit une exception avec une stack trace, calcule une empreinte à partir de celle-ci, puis regroupe des milliers d’occurrences dans un seul problème avec un compteur. Un outil de tracing des LLM reçoit un span contenant un prompt, une réponse, un nombre de tokens et une latence. Il doit conserver chacun de ces éléments, car deux appels avec des entrées identiques restent des événements distincts qu’il est utile de consulter.

Utilisez donc les deux. Envoyez les exceptions à l’outil de suivi des erreurs et envoyez les appels aux modèles vers un outil conçu pour cela : Langfuse self-hosted pour le tracing d’agents couvre cet aspect, tandis que l’observabilité des IA self-hosted aborde le même besoin sous un autre angle. Votre application produit déjà ces deux types d’échec. Un appel de modèle qui renvoie des informations fausses avec assurance ne lève aucune exception. Un outil de suivi des erreurs ne vous le signalera donc jamais.

La croissance du disque est une panne qui vous rattrape plus tard

Tout outil de suivi des erreurs est une base de données à forte activité d’écriture, alimentée par un volume d’entrées sans limite. Votre application détermine la quantité de données écrites. Un nouveau bug dans un chemin de code très sollicité peut produire un million d’événements en une nuit.

GlitchTip publie un chiffre utile pour le dimensionnement : une instance qui traite un million d’événements par mois peut avoir besoin de 30 GB de disque. Cela couvre un mois de collecte à ce rythme. Votre fenêtre de rétention détermine combien de mois sont stockés simultanément.

Bugsink aborde le problème différemment. Au lieu d’appliquer un quota fixe, il utilise un algorithme de rétention fondé sur le nombre et l’âge des événements. Il expose directement les limites : MAX_RETENTION_EVENT_COUNT pour l’installation entière, MAX_RETENTION_PER_PROJECT_EVENT_COUNT par projet et MAX_EVENT_AGE_DAYS comme limite absolue. Définir un budget d’événements pour toute l’installation est la manière honnête de dimensionner le disque, car ce budget correspond à la capacité disque nécessaire.

Surveillez les valeurs réelles sur le serveur :

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v affiche la taille de chaque volume. Vous pouvez ainsi voir quel service consomme l’espace. Lorsqu’un volume gagne plusieurs gigaoctets par semaine sans changement du trafic, cela signifie généralement que la rétention n’a jamais été configurée. Rien n’est donc supprimé et la seule limite est celle de la partition.

La mémoire pose le même problème sous une autre forme. Une stack sans limites consomme toute la mémoire proposée par le kernel. Lorsque la machine est à court de mémoire, l’OOM killer sélectionne le plus gros processus. Il peut s’agir de votre serveur web plutôt que du tracker à l’origine du problème. Fixez une limite à chaque service : limites mémoire dans Docker Compose présente la syntaxe et le comportement d’un conteneur lorsqu’il atteint sa limite. Un conteneur tué par sa propre limite provoque une panne contenue. Un conteneur tué par le kernel entraîne un service voisin avec lui.

Quelle pile choisir selon le VPS

• 1 GB, ou 2 GB avec une marge confortable : GlitchTip en mode tout-en-un avec Valkey désactivé, ou Bugsink avec SQLite. Ces deux options conviennent sans problème à quelques applications.
• 4 GB : Bugsink avec PostgreSQL, ou GlitchTip avec Valkey activé et un service worker distinct. À partir de cette taille, vous pouvez arrêter d’optimiser chaque paramètre et simplement l’exécuter.
• 8 GB : toujours insuffisant pour la pile Sentry officielle. Utilisez plutôt cette capacité pour prolonger la durée de rétention et augmenter la taille du disque de l’option légère que vous avez choisie.
• 16 GB minimum, 32 GB recommandé : la pile Sentry self-hosted officielle, et uniquement lorsque vous avez besoin d’une fonctionnalité Sentry que les projets plus légers n’implémentent pas. Vérifiez d’abord cette fonctionnalité dans la documentation de chaque projet, car les projets compatibles couvrent les besoins courants.

Quelle que soit l’option utilisée, le gestionnaire d’erreurs ne peut pas signaler son propre arrêt. Ajoutez un contrôle depuis une autre machine : Uptime Kuma qui surveille depuis une autre machine vous indiquera que le gestionnaire est hors service. C’est précisément à ce moment que votre application commence à générer des erreurs que personne n’enregistre.

Quand une offre hébergée est la solution la moins chère

L’auto-hébergement d’un outil de suivi des erreurs est rentable lorsque les règles de résidence des données l’imposent ou lorsque le volume d’événements est suffisamment élevé pour rendre la facturation à l’événement pénalisante. Dans les autres cas, faites honnêtement le calcul. Le minimum documenté par Sentry est un serveur avec 16 GB de RAM, 4 cœurs et un disque rapide. Un VPS de cette taille n’est pas bon marché. Il faut ensuite ajouter le travail d’exploitation : franchir chaque point bloquant dans l’ordre et prendre un snapshot avant chaque migration, plusieurs fois par an.

GlitchTip et Bugsink changent complètement ce calcul, car une machine de 512 MB à 4 GB coûte peu cher et la mise à niveau est un docker compose pull. C’est pourquoi la plupart des personnes qui posent cette question finissent par utiliser l’un des projets compatibles plutôt que la stack officielle. Elles voulaient suivre les erreurs, pas surveiller un pipeline de données distribué.

Si vous cherchez encore à déterminer ce qui doit réellement être installé sur le serveur, la liste plus large des services qui valent la peine d’être auto-hébergés place le suivi des erreurs à côté des autres services qui utilisent la même RAM.

FAQ

Puis-je auto-héberger Sentry sur un VPS de 2 GB ?

Non. La documentation de Sentry self-hosted indique un minimum de 4 CPU cores, 16 GB de RAM et 16 GB de swap, ainsi que 20 GB d’espace disque libre. La stack exécute simultanément Postgres, ClickHouse, Kafka, Redis et plusieurs worker processes. Sur une petite machine, le kernel tue donc des containers avant la fin de l’installation. Confirmez-le avec dmesg -T | grep -i 'out of memory', qui affiche une ligne indiquant le processus tué. Pour un VPS de 2 GB, utilisez GlitchTip, qui documente 512 MB, ou Bugsink, qui s’exécute dans un seul container avec SQLite.

Dois-je modifier le code de mon application pour passer de Sentry à GlitchTip ou Bugsink ?

Non. Les deux acceptent les événements des SDK open source de Sentry. Vous pouvez donc conserver le SDK déjà installé et ne modifier qu’une valeur : le DSN, c’est-à-dire l’URL à laquelle le SDK envoie les événements. Déplacez-le dans une variable d’environnement s’il est encore codé en dur, pointez-le vers le nouvel hôte, puis déclenchez une exception de test et vérifiez qu’elle arrive. Si rien ne s’affiche, vérifiez que l’identifiant du projet dans le DSN correspond à un projet existant sur le nouveau serveur et que votre firewall autorise l’application à joindre cet hôte et ce port.

De combien d’espace disque le suivi des erreurs auto-hébergé a-t-il besoin ?

Cela dépend du volume d’événements et de la durée de rétention, pas de l’outil utilisé. GlitchTip indique 30 GB pour une instance traitant un million d’événements par mois. Bugsink vous permet de définir directement le budget avec MAX_RETENTION_EVENT_COUNT et MAX_EVENT_AGE_DAYS. Vous choisissez donc la limite, et le besoin en disque en découle. Configurez la rétention dès le premier jour. Un outil de suivi sans politique de rétention continue de grossir jusqu’à ce que df -h affiche 100 %. À ce moment-là, l’ingestion s’arrête et vous perdez les erreurs que vous aviez le plus besoin de voir.

Pourquoi la mise à niveau de Sentry self-hosted échoue-t-elle toujours ?

Parce que la mise à niveau a ignoré un hard stop. Sentry self-hosted définit des versions précises qui contiennent des migrations de base de données. Vous devez passer par ces versions. En août 2026, il s’agit de 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 et 26.7.0. Passer directement d’une ancienne release à la plus récente ignore ces migrations. Le schéma et le code ne correspondent alors plus, et la mise à niveau s’arrête en cours de route. Faites un checkout de chaque hard stop dans l’ordre et exécutez ./install.sh à chacun d’eux. Créez un snapshot du serveur avant de commencer et consultez la liste documentée des releases à éviter, qui comprend 23.7.0, 25.9.0 et 25.12.0.