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.
Snapshote un conteneur template de démo, puis /copy le cinquante fois. Chaque prospect arrive sur son URL avec son logo, ses données seed, ses intégrations. Quarante-huit environnements idle ne coûtent presque rien — seuls les deux en appel en ce moment font du vrai travail.
Un snapshot, un appel /copy par prospect, un petit script de seed. Hoody Containers API et Container Snapshots API font le vrai travail. votre sales engineer câble le tout en vingt lignes de bash.
POST sur l'endpoint snapshots de votre conteneur de référence. L'artefact est un snapshot d'état complet — fichiers, processus, mémoire — de la démo que votre sales engineer a peaufinée le trimestre dernier.
POST /containers/$BASE/snapshotsPour chaque prospect, POST sur l'endpoint /copy avec source_snapshot. Le nouveau conteneur démarre en quelques secondes, sur le serveur qui a de la marge, identique à la base à part son ID et son URL.
POST /containers/$BASE/copyLancez un script exec one-shot sur le nouveau conteneur qui change le logo, insère les noms de son équipe, simule son usage des trente derniers jours. Même script pour chaque prospect, paramétré par nom de société.
exec seed.sh $COMPANYEmail ou Slack au prospect avec son sous-domaine fonctionnel. Il clique. Il joue avec. Il le forward à son CTO. Quarante-huit autres restent assis sur le serveur flat-rate que vous louez déjà — KSM dédupe leurs pages RAM, BTRFS dédupe leurs blocs disque. L'idle n'a pas de ligne séparée.
https://$CO.demo.your-app.comPromotion à la signature avec un PATCH. Destruction au ghost avec un DELETE. Le même mécanisme /copy alimente les sandboxes par client une fois le prospect converti — même forme, tier différent.
Un Loom, c'est la démo du produit de quelqu'un d'autre. Un sandbox, c'est une démo avec les données de quelqu'un d'autre. Un environnement fonctionnel avec son logo et ses chiffres, c'est ce que les prospects forwardent à leur CFO.
La démo n'est pas un partage d'écran de 30 minutes. C'est une URL que le prospect ouvre depuis son laptop le mardi et depuis son téléphone le vendredi. Il la montre à un collègue. Il la colle dans un thread Slack. Le deal mûrit pendant que vous dormez.
Les clouds par VM facturent les cinquante environnements, que quelqu'un visite ou non. Sur Hoody, les conteneurs idle partagent la RAM de l'image de base (KSM) et le disque (BTRFS CoW) ; le coût marginal de la quarante-huitième démo, c'est le delta de ce qui a changé, pas une instance complète.
Quand un prospect signe, le même conteneur devient son tenant. PATCH le tier de demo à production, route son domaine custom. Pas de migration de données, pas d'onboarding de zéro, pas de friction « maintenant on va configurer votre vrai compte ».
Mêmes cinquante environnements. Facture différente, latence différente, ménage différent. Les chiffres ci-dessous viennent du modèle de conteneur Hoody documenté — votre tier de serveur et votre densité varieront.
Dyno Heroku Standard-1X ≈ $1/mo × 50 ≈ $1,200/mois pour cinquante. Le prix bare-metal Hoody démarre à $1/mo ; $1/mo illustre un serveur mid-tier hébergeant des dizaines de conteneurs via la densité KSM/BTRFS — pas le tier d'entrée.
Chaque prospect reçoit une version fonctionnelle de votre produit. Pas un Loom. Pas un sandbox. La sienne.
Les façons standard pour les équipes de tendre une démo personnalisée à un prospect aujourd'hui. Chacune vous facture par environnement, par minute en appel, ou par tour de « je vous renvoie le lien ».
Arrêtez de démontrer votre produit. Commencez à le tendre pendant une semaine.