Qu'est-ce que Buggregator ?

Buggregator est un serveur de débogage local livré comme un seul conteneur Docker, qui agrège dans une même interface web les dumps, les emails SMTP, les exceptions Sentry, le profiling XHProf, les logs Monolog et les HTTP dumps. Il est open source sous licence MIT.

Comment démarrer Buggregator ?

Il s'installe en une commande Docker (« docker run ghcr.io/buggregator/server:latest »). L'interface est disponible sur http://127.0.0.1:8000, et les ports 1025 (SMTP), 9912 (Ray) et 9913 (HTTP dumps) reçoivent les flux de debug de l'application.

Buggregator est-il adapté à la production ?

Non, ce n'est pas son rôle : c'est un outil de développement qui n'est pas conçu pour la rétention longue durée. En production, on garde une vraie stack d'observabilité.

Buggregator : serveur de debug PHP local

📚 Introduction

Sur une application PHP moderne, on finit par accumuler une dizaine d’outils pour déboguer : MailHog, un Sentry local, Ray, XHProf, un viewer Monolog, un proxy HTTP. Chacun est utile, mais l’addition fait beaucoup à installer et maintenir.

Buggregator propose une approche radicale : un seul conteneur Docker, une seule interface web, tous ces outils intégrés et corrélés. Tout reste en local, rien à modifier dans le composer.json, et c’est open source sous licence MIT.

🚀 Démarrage en 30 secondes

L’installation tient en une commande Docker. La version recommandée par la doc expose aussi les ports SMTP, Ray et HTTP dumps :

docker run --pull always \
  -p 127.0.0.1:8000:8000 \
  -p 127.0.0.1:1025:1025 \
  -p 127.0.0.1:9912:9912 \
  -p 127.0.0.1:9913:9913 \
  ghcr.io/buggregator/server:latest

L’interface est disponible sur http://127.0.0.1:8000. Les autres ports correspondent au SMTP (1025), au protocole Ray (9912) et au capteur de HTTP dumps (9913). À partir de là, on configure les variables d’environnement de son application pour pointer les flux de debug vers Buggregator. Quelques exemples côté Laravel ou Symfony :

# Sentry vers Buggregator
SENTRY_LARAVEL_DSN=http://sentry@127.0.0.1:8000/1
 
# Mailer SMTP vers Buggregator
MAIL_MAILER=smtp
MAIL_HOST=127.0.0.1
MAIL_PORT=1025
 
# Monolog HTTP handler vers Buggregator
LOG_CHANNEL=stack

Pas de SDK propriétaire, pas de wrapper à installer : Buggregator parle nativement les protocoles déjà supportés par votre application.

🧰 Tout dans une seule interface

Buggregator agrège dans la même UI :

Exceptions Sentry avec stack trace complète et tagging.
Emails SMTP : remplacement direct de MailHog ou Mailtrap.
Dumps de variables : compatible VarDumper de Symfony et Ray.
Profiling XHProf : flame graphs lisibles directement dans l’UI.
Logs Monolog : agrégation des flux de log applicatif.
HTTP Dumps : inspection des requêtes sortantes via le mode proxy.
SMS et autres événements pour les outils internes ou services tiers.

Tout est corrélé sur la même timeline : quand une requête échoue, on retrouve l’exception, le dump, le log Monolog et les emails envoyés sans changer d’onglet.

🧱 Architecture et intégration

L’outil est livré comme un conteneur Docker indépendant. Il ne touche pas à votre application :

Compatible Laravel, Symfony, Spiral, WordPress, Drupal, Yii3, et toute app PHP.
Compatible runtimes modernes : Laravel Octane, FrankenPHP, Swoole, RoadRunner.
Aucune modification du composer.json : on l’active ou on le coupe sans toucher au code.
Package optionnel buggregator/trap : helpers trap(), tr(), td() pour dumper depuis le code, non obligatoire.
Plugin PhpStorm pour ouvrir fichier/ligne d’un dump ou stack trace dans l’IDE.

🎯 Quand utiliser Buggregator

Mon arbitrage actuel :

Développement local : installation automatique sur tous mes projets PHP. Le gain est immédiat dès le premier debug.
Staging interne ou ateliers d’équipe : un Buggregator partagé permet à plusieurs développeurs d’observer ensemble les flux d’une application.
Tests E2E en CI : on peut le démarrer comme service GitHub Actions et vérifier après coup les emails et exceptions capturés pendant les tests.
Production : ce n’est pas son rôle. En production, on garde une vraie stack d’observabilité (SigNoz avec OpenTelemetry est mon défaut).

🔒 Côté confidentialité

C’est un argument particulièrement appréciable pour les projets sensibles (santé, finance, secteur public) :

Toutes les données restent sur la machine locale ou le serveur self-hosted.
Aucun compte SaaS à créer.
Aucun trafic sortant vers un tiers.

Pour les développeurs habitués à voir leurs payloads applicatifs partir chez un éditeur cloud, c’est un soulagement non négligeable.

🤖 Serveur MCP intégré : déboguer avec un agent IA

C’est la fonctionnalité que je n’avais pas vue venir, et probablement la plus différenciante de Buggregator côté 2026 : un serveur MCP intégré qui permet aux assistants IA (Claude Code, Cursor, etc.) d’interroger directement les événements de debug, sans quitter l’éditeur.

Activation

mcp:
  enabled: true

Ou via variable d’environnement :

MCP_ENABLED=true

Deux transports disponibles : socket Unix (/tmp/buggregator-mcp.sock par défaut, idéal en dev local), ou HTTP/SSE sur le port 8001 (recommandé en Docker). Exemple complet en HTTP :

mcp:
  enabled: true
  transport: http
  addr: ':8001'
  auth_token: my-secret-token

Outils MCP exposés

Le serveur expose plusieurs outils :

Événements : events_list, event_get, event_delete.
Sentry : sentry_event (stack trace, contexte, environnement).
VarDumper : vardump_get (dumps rendus en texte brut, lisible par l’agent).
Profiler : profiler_summary, profiler_top, profiler_call_graph.

Configuration Claude Code

Pour une instance Buggregator déjà lancée en Docker, on déclare un MCP HTTP dans le .mcp.json du projet :

{
	"mcpServers": {
		"buggregator": {
			"type": "http",
			"url": "http://localhost:8001/mcp"
		}
	}
}

Côté docker-compose.yml, l’exposition de l’endpoint MCP tient en quelques lignes :

services:
  buggregator:
    image: ghcr.io/buggregator/server:latest
    ports:
      - 127.0.0.1:8000:8000
      - 127.0.0.1:8001:8001
    environment:
      MCP_ENABLED: 'true'
      MCP_TRANSPORT: http
      MCP_ADDR: ':8001'

Ce que ça change concrètement

Sur une session de debug, on peut demander à l’agent :

“Affiche les 5 dernières exceptions Sentry et regroupe-les par cause.”
“Quelle est la stack trace de l’événement abc-123 ?”
“Identifie les fonctions les plus coûteuses dans le dernier profiling.”

L’agent ne se contente plus de proposer du code à l’aveugle : il lit les vrais événements générés par votre application. Couplé à Laravel Boost, qui expose l’application elle-même, l’agent peut lire le code, exécuter Tinker, déclencher des requêtes et inspecter le résultat dans Buggregator, dans la même conversation.

⚠️ Sécurité du MCP

En socket Unix local, l’accès est restreint à l’utilisateur de la machine. Bon réflexe pour le dev.
En HTTP, toujours définir un auth_token. Et garder le port mappé sur 127.0.0.1 sauf besoin explicite.
Le MCP donne accès aux événements bruts : ne pas l’activer en production sans contrôle d’accès strict.

⚠️ Quelques précautions

Ne pas exposer l’instance publiquement. Le mapping par défaut sur 127.0.0.1 est le bon réflexe : tout ce qui est exposé sur Internet doit être derrière une authentification.
Mémoire : la rétention peut grimper rapidement sur une session intensive. Penser à purger régulièrement ou à monter un volume dédié.
Compléter, pas remplacer : pour la production et la rétention longue durée, Buggregator n’est pas conçu pour ça. C’est un outil de développement.

🎉 Conclusion

Buggregator coche les bonnes cases : installation triviale, couverture large, compatibilité avec les SDK déjà utilisés, vraie confidentialité. C’est le genre d’outil qu’on regrette de ne pas avoir installé plus tôt — il remplace toute une étagère d’outils par une UI cohérente. Si vous avez encore plusieurs conteneurs séparés pour MailHog, un mock Sentry et un serveur de dumps, c’est le bon moment pour faire le ménage.

🐞 Buggregator : le serveur de débogage tout-en-un pour PHP