La plupart des pros qui gèrent de l’infra en prod jonglent avec 3 à 5 outils : un pour les conteneurs, un pour l’uptime, un pour les certs, un pour les métriques, un pour la status page. Chacun avec sa stack, sa base de données, sa courbe d’apprentissage, son budget RAM. Maintenant consolide tout ça derrière une seule interface, dans un seul process, sous moins de 30 Mo de RAM.
Ce que ça faitAuto-discovery des conteneurs Docker, Swarm et Kubernetes — runtime auto-détecté, RBAC read-only sur K8s avec filtrage par namespace. Checks HTTP/TCP déclarés par labels Docker (pas de YAML séparé à maintenir). Heartbeats pour les crons (curl une URL, on suit l’exit code). Suivi des certificats TLS avec alertes à 30/14/7/3/1 jours. Métriques CPU/mémoire/réseau/disk avec historique. Update Intelligence : scan des registries OCI, comparaison de digests, enrichissement CVE via OSV.dev avec risk scoring (Pro). Alertes unifiées toutes sources confondues — Webhook et Discord en CE, Slack/Teams/Email en Pro. Status page publique avec composants et incidents. Serveur MCP intégré (stdio + Streamable HTTP avec OAuth2). Principe fondamental : observe-never-act. Socket Docker monté en read-only. Maintenant ne redémarre rien, ne touche à rien, c’est un observateur pur. C’est aussi un argument commercial pour les clients qui ne veulent pas qu’un outil tiers ait les pleins pouvoirs sur leur stack.
C’est un bel outil mais n’est pas encore prêt pour gérer plusieurs machines (https://github.com/kOlapsis/maintenant/issues/12). Il ne peut donc pas remplacer les outils de monitoring qui savent faire ça (Beszel, Uptime Kuma pour ne citer qu’eux).
La version AGPL est suffisamment bridée / incomplète pour limiter grandement son évaluation (gestion des maintenances et des incidents non dispos). C’est dommage je trouve.
Merci pour le retour, c’est utile.
Petite précision sur les comparables : Beszel est effectivement multi-server natif via son architecture hub et agents distribués, sur ce point tu as raison. Uptime Kuma en revanche ne l’est pas au sens “agents distribués sur plusieurs hôtes” : c’est une instance unique qui sonde des cibles accessibles via le réseau (HTTP, TCP, ping, certs SSL). Et ce pattern là, Maintenant le couvre déjà aujourd’hui : tu peux créer autant de sondes HTTP, TCP et de monitors de certificats TLS que tu veux vers des hôtes externes depuis une seule instance. Sur ce terrain, on est au même niveau.
Là où Maintenant est aujourd’hui mono hôte, c’est sur l’auto discovery des containers et les métriques de ressources locales (CPU, RAM, réseau par container). C’est précisément le sujet sur lequel je travaille en ce moment, agents distribués pour étendre cette partie là sur plusieurs hôtes. C’est la prochaine étape majeure du produit.
Enfin sur la version AGPL bridée : c’est un choix délibéré, le projet a besoin de financer son développement. Mais si tu identifies des limites qui empêchent vraiment une éval honnête du produit, je suis preneur du retour précis, ça peut faire évoluer ce qui est inclus dans la Community.
Merci pour ton retour.
De mon côté, j’ai un besoin de monitoring multi-serveur que je couvre avec Beszel (sondes système et Docker) et Uptime Kuma (sondes HTTP/TCP, certificats SSL), avec des notifications par mail et Matrix. J’ai aussi une gestion des maintenances pour limiter les notifications, ainsi que des pages de statut. J’ai deux contextes de monitoring : mon infra auto-hébergée de CHATONS et mes machines perso, ainsi qu’une infra pour une activité pro.
Pour la partie perso, j’ai pas mal de services à monitorer et je dépasse largement les limites documentées : endpoints HTTP/TCP (10 max), certificats SSL/TLS (5 max). Je ne peux pas tester les notifications par mail ni gérer les fenêtres de maintenance (quasi indispensables). La gestion des incidents n’est pas un problème, car j’ai développé un outil dédié, mais si l’objectif est de limiter le nombre d’outils, autant pouvoir tester aussi cette partie.
Si je mets de côté la notion de multi-serveur, qui n’est pas développée et qui rend l’outil impossible à installer dans mon infra perso (voire pro si ça venait à bien fonctionner), je ne pourrais même pas tester ne serait-ce que les notifications.
Côté financement, je comprends tout à fait ton besoin. En revanche, je trouve que ce n’est vraiment pas donné (29 € x 11 machines / mois juste pour mes besoins perso, ça fait mal). Dans le cas où la solution était multi-serveur, j’aurais un intérêt à externaliser le monitoring, et c’est peut-être là qu’il pourrait y avoir une source de revenus plus pertinente : je paie le serveur de monitoring et j’installe des agents sur mes machines (ou bien je fais du ping).
Je comprends, mais petite mise au point, le tarif restera unique, je n’aime pas les prix par siège ou serveur, ce sera donc dans ton cas, 29€ pour les 11 machines, pour le coup ca me semble correcte :D Pour les limites, sur les endpoints par exemple c’est un peu plus souple que tu ne le crois, c’est 10 via l’UI, mais j’ai délibérément laissé illimité via les labels (si tu as 15 apps exposés, tu peux monitorer les 15, mais tu ne pourras pas en ajouter plus via l’UI (idem pour le reste)