Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Un job nocturne qui scanne les exceptions de facturation de la veille, regroupe les doublons et écrit une note de triage. Il n'a besoin d'exister qu'environ une heure par jour. Deux entrées cron lancent un conteneur agent frais à 02:59 et le démontent à 04:01. Les 23 autres heures, il ne tourne pas, n'est pas warm, n'est pas facturé.
Un agent. Une heure par nuit. Idle les vingt-trois autres. La facture du serveur à tarif fixe ne change pas dans un sens ou dans l'autre.
Pas de pool warm, pas de service de scheduler, pas de daemon de glu qui poll pour du boulot. Une entrée hoody-cron POST sur l'URL spawn de hoody-agent à 02:59. L'agent fait son run et sort. Un deuxième cron à 04:01 appelle DELETE pour s'assurer que le conteneur est bien parti. C'est toute la machine.
Deux lignes cron dans une base. Une image agent. Le conteneur n'existe que pour le boulot, puis il cesse d'exister. Pas de pool warm, pas de primitive de tâche planifiée, pas de daemon de cycle de vie à opérer vous-même.
Cinq moments. L'agent est vivant pour les trois du milieu. En dehors de cette heure, la ligne dans la table conteneurs a disparu.
L'entrée cron billing-reconcile-wake se déclenche. Elle POST sur api.hoody.com avec ai: true et hoody_kit: true. Un conteneur frais est lancé avec un filesystem propre et le prompt de l'agent chargé.
L'agent lit la table billing-exceptions d'hier via Hoody SQLite et demande à un LLM de regrouper les lignes par code de motif — soit via le Hoody AI Gateway (coût provider + 5%, pris sur votre AI Balance), soit en BYO key direct vers Anthropic / OpenAI / votre provider. Pas de mounts de file-share. Juste des URLs.
Il écrit une seule note de triage par cluster vers la même URL SQLite, puis envoie une notification avec le résumé du jour. Temps total écoulé jusqu'ici : environ trente minutes.
Le process agent retourne 0 et le conteneur sort tout seul. Hoody-conteneurs le marque stopped. À partir de cette seconde, rien de l'agent ne tourne, n'est warm, ni facturé.
Une deuxième entrée cron déclenche DELETE sur l'id du container. Si l'agent est déjà sorti, c'est un no-op 200 OK. S'il est resté pendu, le conteneur est démonté quand même. Idempotent et sans surveillance.
Cinq timestamps, deux lignes cron, un conteneur qui vit soixante-deux minutes. La nuit tourne toute seule, et vous apprenez qu'elle a tourné en lisant la note de triage le matin.
Un worker always-on, c'est la mauvaise forme pour un job qui tourne une fois par jour. Sur Hoody, le substrat est à tarif fixe — la victoire n'est pas la facturation à la seconde, c'est l'absence de pool warm, de service de scheduler, de daemon de glu à opérer.
Pas de pool warm assis en mémoire. Pas de service de 'tâche planifiée' qui garde de l'état. La ligne dans la table conteneurs disparaît pendant vingt-trois heures de la journée. Le serveur à tarif fixe que vous louez déjà fait tourner le boulot ; les heures idle ne génèrent pas de ligne séparée.
Hoody facture la box, pas le runtime. Un agent nocturne de 60 minutes et un worker always-on 24/7 atterrissent sur la même facture de serveur à tarif fixe. La victoire n'est pas 'paie seulement ce que vous utilisez' — c'est ne pas payer deux fois pour une surcharge de pool warm dont vous n'avez pas besoin.
vous n'écris pas de Lambda de réveil, de worker 'fais tourner le conteneur', ni de watchdog qui le retire. Hoody-cron POST. Hoody-conteneurs spawn. L'agent sort. Un deuxième cron POST DELETE. C'est toute la surface.
La plupart des plateformes d'agent gardent le worker warm vingt-quatre heures sur vingt-quatre pour qu'il soit prêt en moins d'une seconde. Pour un batch job de 3h du matin, c'est exactement le mauvais tradeoff. Cold-spawn en quelques secondes, c'est très bien quand le planning est le tien.
Un conteneur agent always-on, ou une place de pool warm réservée pour un agent qui tourne une fois par jour, est vivant 720 heures par mois. 719 de ces heures, il ne fait rien.
Idle est la ligne sur les plateformes par-secondeUn conteneur éphémère lancé par une entrée cron existe pendant une heure par nuit. Trente heures par mois, total. Le process agent retourne 0 et la ligne dans la table conteneurs a disparu.
Hoody facture le serveur, pas le runtime. La colonne 'vivanvous montre quand l'agent existait chaque nuit — le même serveur à tarif fixe tourne qu'il soit là ou non. Le pricing démarre à $1/mo et varie selon la spec, la région et la durée de location.
Un agent qui n'existe que quand il y a du boulot à faire.
Les patterns qui paient pour qu'un agent existe 24/7. Sur Hoody, l'agent tourne dans le serveur à tarif fixe que vous louez déjà — pas de pool warm, pas de service de scheduler, pas de compteur par-seconde.
Un agent qui n'existe que quand il y a du boulot à faire.