Un hébergement ennuyeux est une fonctionnalité : comment Notis tourne sur Render

Le plus beau compliment qu’on puisse faire à un hébergeur, c’est d’avoir oublié qu’il était là.

Notis tourne sur Render. J’ai fait le tour des alternatives (la phase Kubernetes, la phase VM brute, la phase plateforme aux mille réglages), et pour un produit mené par son fondateur, ce que j’attends de l’infrastructure, c’est qu’elle ne devienne pas un deuxième job.

Ce qui tourne vraiment là-bas

Notis n’est pas un service unique, et sa forme compte.

Le backend Python/FastAPI porte le produit : la boucle de l’agent, l’entrée et la sortie des canaux, la distribution des outils, les automatisations, la logique de facturation. C’est le cœur, et il vit sur Render. Les tâches planifiées (passes de nettoyage, envois de notifications, maintenance) y tournent aussi.

D’autres éléments vivent ailleurs, volontairement. Le Portal Next.js est hébergé là où Next.js est le plus à l’aise. Les environnements éphémères du Cloud Computer tournent chez un fournisseur de sandbox conçu exactement pour ça. Le vrai rôle de Render, c’est la partie toujours active : des services qui doivent être joignables, dans une région qu’on a choisie, avec un processus de déploiement qui ne demande pas de réunion.

Tout est à Francfort. Ce n’est pas une préférence esthétique. Notis est exploité par une entreprise suisse dont les utilisateurs sont surtout européens, et l’endroit où se trouve le calcul fait partie de la réponse sur la confidentialité. C’est pour ça que Render apparaît nommément, certifications à l’appui, dans la présentation des fournisseurs de la plateforme de notre centre d’aide.

Le problème de l’IP statique, et le petit service qui l’a réglé

Ce que je préfère parmi tout ce qu’on fait tourner sur Render, c’est trente lignes de configuration.

Plusieurs services dont Notis dépend, dont OpenAI et Composio, filtrent les adresses IP sortantes par liste d’autorisation. Or nos sandboxes Cloud Computer sont éphémères par conception et n’ont pas d’identité de sortie stable. Ces deux faits sont incompatibles.

La solution, c’est un minuscule relais hébergé sur Render : un service web sans état dont le seul but est de donner au trafic des sandboxes une adresse sortante statique autorisée. Les sandboxes s’y connectent via WebSocket, et le relais ne transfère que vers une liste explicite d’hôtes de destination. Tout ce qui n’a pas besoin de l’IP autorisée passe en direct, parce que faire transiter du trafic par un intermédiaire inutile ne fait qu’ajouter de la latence et un point de défaillance.

Il n’a ni état ni disque, il peut donc être redéployé et mis à l’échelle librement. Il est à Francfort parce que c’est la région dont les adresses sortantes figurent sur la liste d’autorisation. Trompe-toi là-dessus et tu passeras un après-midi à te demander pourquoi une liste d’autorisation ne fonctionne pas.

C’est un petit truc. Mais c’est exactement le genre de petit truc trivial sur une plateforme où lancer un service tient dans un fichier YAML, et qui devient un projet entier sur une plateforme où c’est une décision de cluster.

La discipline de configuration

Une pratique que je recommande à tout le monde, quelle que soit la plateforme : les variables d’environnement appartiennent à un groupe, pas à un service.

On gère la configuration via des groupes d’environnement partagés, et la liste de variables propre à chaque service reste vide. Ça a l’air pédant. Ça évite une panne précise et coûteuse : deux services censés partager un identifiant qui divergent parce que quelqu’un a corrigé l’un d’eux en urgence à minuit.

Avec une configuration groupée, chaque valeur vit à un seul endroit. Faire tourner une clé, c’est un seul changement. Vérifier ce qui est défini, c’est une seule liste. Et quand une valeur est fausse, elle est fausse partout à la fois, ce qui est bien plus facile à diagnostiquer qu’une erreur à un seul endroit.

Ça rend aussi la configuration lisible par une machine, de façon utile : je peux vérifier l’état d’un groupe via l’API au lieu de cliquer dans un Dashboard, ce qui veut dire qu’un agent de code peut vérifier la configuration dans le cadre d’une tâche au lieu de me demander d’aller voir.

Pourquoi ne pas aller moins cher ou plus bas niveau

Je pourrais faire tourner tout ça sur de simples VM pour moins cher. Je l’ai déjà fait. Voici ce que ça t’achète vraiment : la maintenance des images de base, les correctifs de sécurité, un pipeline de déploiement que tu as écrit, une agrégation de logs que tu as câblée, des health checks que tu as réglés, et une astreinte qui, c’est toi.

Pour une équipe de ma taille, la bonne question n’est pas « quel est le calcul le moins cher ». C’est « quel est le calcul le moins cher en comptant les heures ». Ces heures sont la ressource la plus rare de toute l’entreprise, et elles sont bien mieux investies dans le bon comportement de l’agent que dans la question de savoir pourquoi systemd est mécontent.

Le contre-argument est réel : les plateformes gérées coûtent plus cher à l’unité et donnent moins de contrôle à la marge. Quand on a touché ces limites (l’IP statique, le verrouillage de région, les services dont le disque les attache à une seule instance), la réponse a toujours existé, en demandant juste parfois un paragraphe de lecture. C’est un bon marché.

Si tu choisis une infrastructure pour un petit produit

1. Optimise pour les heures, pas pour le prix de l’instance. Refais le calcul chaque fois que quelqu’un te montre une VM moins chère.
2. Choisis ta région délibérément, surtout si tu fais des promesses sur la confidentialité. C’est aussi là que les listes d’autorisation mordent.
3. Garde la configuration dans des groupes, laisse les surcharges par service vides. La dérive est l’ennemi.
4. Laisse ce qui est sans état rester sans état. Dès qu’un service a un disque, il n’est plus librement redéployable, et tu dois savoir lesquels sont concernés.
5. N’héberge pas tout au même endroit par souci de rangement. Associe chaque charge de travail à l’outil conçu pour elle.

Notis est mené par son fondateur, exploité en Suisse et livre en continu. Presque aucune de ces livraisons n’implique de penser aux serveurs.

Render y est pour beaucoup.