Articles and insights about Agata Stack.
Des Procfiles, des configs supervisord et un cimetière de scripts shell pour gérer les services de dev. Voici pourquoi j’ai arrêté de tout maintenir, et ce que j’utilise maintenant.
Le triage des logs est pénible parce que les erreurs arrivent comme un flux, pas comme une histoire. La chronologie d'Agata Stack transforme chaque événement correspondant à une règle en une entrée codée par couleur que vous pouvez lire comme une timeline — voici comment ça marche et pourquoi le code couleur compte plus qu'il n'y paraît.
L’API HTTP locale d’Agata Stack vous permet de démarrer, arrêter, redémarrer et suivre les logs de n’importe quel service sur votre Mac avec une simple commande curl — depuis la CI, un alias shell ou un outil IA. Pas de config de daemon, pas de service tiers.
Se connecter en SSH à une machine de staging à chaque fois qu’on veut vérifier un log, c’est du DevOps de 2010. Voici comment des services distants peuvent cohabiter avec les locaux dans la même vue d’état, avec les mêmes vérifications de santé, flux de logs et règles d’automatisation.
Vous pouvez maintenant pointer Claude Code ou Cursor vers votre iOS Simulator ou votre émulateur Android en cours d’exécution, prendre des captures d’écran, exécuter des commandes adb shell et installer des builds — le tout depuis une invite IA, depuis votre barre de menus, sans jamais changer d’application.
La plupart des serveurs MCP exigent un processus séparé, un relais cloud, ou ne couvrent qu’une seule chose. Agata Stack exécute son point de terminaison MCP dans l’app de barre de menu elle-même — pour l’usage de l’ordinateur, le QA mobile, la gestion des services et le flux des logs depuis une seule adresse localhost.
Votre assistant de code IA peut voir votre code. Il ne peut pas voir si votre serveur de dev tourne vraiment. Voici comment une API HTTP locale et un point de terminaison MCP changent complètement la donne.
Changer de contexte entre les environnements dev, staging et production est lent et fragile. Les profils d’environnement dans Agata Stack changent tout en un clic — et l’API permet aussi de le faire depuis vos scripts.
Un contrôle de santé en échec n’est pas un diagnostic. Voici comment Agata Stack lit les 20 dernières lignes de logs, repère les motifs d’erreur connus et vous donne une commande de correction exécutable avant même que vous n’ouvriez un terminal.
La plupart des équipes se tournent vers un service tiers de disponibilité dès qu’elles ont besoin de vérifications de santé. Vous avez déjà tout ce qu’il faut sur votre Mac — et sans coût supplémentaire.
Vous pouvez détecter en temps réel les réponses API lentes de votre stack de dev sans toucher une seule ligne de code ni ajouter de middleware. Voici comment les règles de flux d’Agata Stack fonctionnent sur vos journaux existants.
Les crashs font du bruit. Les échecs silencieux, non. Voici comment détecter le pire type d’incident — le service qui s’arrête simplement en silence — avant vos utilisateurs.
Chaque développeur a perdu cinq minutes à cause d’une erreur de port déjà utilisé au démarrage. Voici la règle de flux qui détecte EADDRINUSE dans vos logs, tue le port bloquant et redémarre votre service — automatiquement, sans terminal.
Agata Stack exécute un serveur HTTP local sur le port 19877. Suivez les logs en direct via SSE, gérez les services, et interrogez une spec OpenAPI auto-descriptive — le tout depuis un script shell, une tâche CI ou un outil IA.
Une ligne d’erreur répétée 400 fois ressemble à du bruit. Mais c’est un motif — et la bonne règle peut l’attraper dès les 5 premières lignes, se déclencher une fois, puis se taire ensuite. Voici comment fonctionne le fingerprinting des logs dans Agata Stack.
La plupart des outils de dev n’affichent que les logs des processus qu’ils ont démarrés. Agata Stack peut se connecter à n’importe quel processus utilisateur en cours d’exécution sur votre Mac — par PID — et diffuser sa sortie en temps réel, sans redémarrage.
Un service en panne que personne ne repère avant qu’un utilisateur ne se plaigne est un problème résolu. Voici la configuration de détection de crash et de redémarrage automatique qui a mis fin aux surprises de 3 h du matin.
Quatorze onglets de terminal, des groupes de fenêtres codés par couleur, et je ne pouvais toujours pas voir d’un coup d’œil quel service était discrètement tombé en panne. Voici ce qui a changé.