
Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Votre produit d'agent crée une sandbox par session. Sur E2B, Modal, Daytona, Runpod ou Replicate, c'est facturé à la seconde et la ligne d'infra IA dans votre P&L finit par dépasser celle des LLM. Sur Hoody, chaque session est un conteneur sur le serveur que vous payez déjà. La 50 000ᵉ sandbox du mois coûte autant que la première : zéro marginal.
même charge · économie différente · le compteur s'arrête
Le modèle mental de l'agent ne change pas. Lancer une sandbox, y exécuter du code, la jeter. Ce qui change, c'est la facture en dessous. Sur E2B, chaque seconde de chaque sandbox est facturée ; sur Hoody, vous faites un POST d'un conteneur sur le serveur que vous louez déjà et le compteur ne démarre jamais.
Les deux côtés font le même travail. La forme de l'API correspond — lancer, exécuter, jeter. C'est la ligne de prix qui bascule : de par-seconde-par-sandbox à fixe-par-serveur. Les conteneurs au repos ne coûtent rien sur Hoody car ils partagent le métal que vous avez déjà payé.
Le code de l'agent change à peine. Trois étapes et la ligne facturée de votre P&L devient fixe. Le plus dur, c'est de retirer le SDK qui vous facturait avant.
Là où vous appeliez le SDK E2B, vous faites POST sur /api/v1/projects/$PID/containers avec un server_id. La réponse vous donne un id de conteneur de 24 caractères et un hostname routable. Le conteneur démarre depuis votre snapshot en quelques secondes — même forme d'objet qu'une référence de sandbox.
Chaque conteneur embarque Hoody Exec — isolates V8, routage par fichier, magic comments pour cors, timeout et concurrence. Déposez votre script runner dans scripts/1/, faites POST avec un payload, récupérez du JSON. Aucun serveur web à câbler, pas d'Express, pas de config Lambda.
Session terminée ? DELETE /api/v1/containers/[id] et c'est parti. Pas envie de s'embêter ? Les conteneurs au repos sur Hoody partagent le métal — ils restent à coût marginal nul jusqu'à ce que vous fassiez DELETE ou jusqu'à ce que le serveur soit plein. Pas de cron de nettoyage, pas de facture orpheline.
Quand le compteur s'arrête, trois choses qui coûtaient cher deviennent gratuites — et votre produit d'agent commence à se comporter comme l'architecture que vous rêviez de pouvoir vous offrir.
Avec un compteur à la seconde, une semaine virale est une taxe. Sur du bare metal à tarif fixe, votre nombre de lancements se détache de votre facture — il est limité par la capacité de la machine, pas par votre facture. Vous pouvez laisser les utilisateurs marteler l'agent sans broncher.
Les sandboxes facturées à la seconde doivent mourir vite — chaque minute au repos, c'est de l'argent. Sur Hoody, le repos est gratuit, donc un utilisateur en pause peut revenir le lendemain et le conteneur est toujours là avec son état. La fidélisation devient gratuite.
Chaque conteneur est son propre vrai OS — namespaces kernel, système de fichiers complet, sa propre URL. Connectez-vous en SSH si vous voulez. Montez /ramdisk. Installez n'importe quel paquet apt dont l'agent a besoin. Même isolation que du bare metal, sans la taxe à la seconde.
Chiffres tirés de l'API Containers et des quotas serveur Hoody — pas inventés. La dalle bare metal fait le gros du travail ; l'API distribue simplement les emplacements.
Il n'y a pas de compteur sandbox-secondes. Les conteneurs ne facturent pas à la seconde ; le serveur facture à tarif fixe. Chaque lancement, chaque retry, chaque minute au repos est à coût marginal nul sur la machine que vous louez déjà.
KSM (Kernel Samepage Merging) et le copy-on-write BTRFS permettent à un seul serveur de tenir des centaines de conteneurs — le second conteneur ne coûte que ce qui diffère du premier. La densité dépend de la charge, mais les sessions d'agent légères s'empilent dense.
La tarification serveur Hoody démarre sur le marketplace à quelques dizaines d'euros par mois et évolue selon les specs, pas selon le nombre de tenants. La facture cesse d'être fonction du nombre d'agents que vous lancez.
La densité de conteneurs dépend de la charge — les sandboxes légères s'empilent par centaines, les agents GPU demandent plus de marge. La tarification serveur est pilotée par le marketplace et varie selon la région, le CPU, la RAM et le disque. Le point clé : quoi que vous payiez, vous arrêtez de payer à nouveau par lancement.
Vos agents arrêtent de louer du calcul à la seconde et commencent à utiliser du calcul déjà payé.
La pile sandbox-as-a-service par défaut vous facture par seconde et par sandbox. Même travail, facture différente. Concrètement, ça déplace :
Arrêtez de louer du calcul à la seconde. Utilisez le calcul que vous avez déjà payé.