
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.
Snapshotez un conteneur demo-template, puis /copy le cinquante fois. Chaque prospect arrive sur sa propre URL avec son logo, ses données seed, ses intégrations. Quarante-huit environnements au repos coûtent presque rien — seuls les deux en appel maintenant font du vrai travail.
Un snapshot, un appel /copy par prospect, un petit script de seed. L'API Hoody Containers et l'API Container Snapshots font le vrai travail. Votre sales engineer les câble en vingt lignes de bash.
POST sur l'endpoint snapshots de votre conteneur de référence. L'artefact est un snapshot full-state — 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 défini. Le nouveau conteneur démarre en quelques secondes, sur le serveur ayant de la marge, identique à la base sauf pour 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 d'équipe, simule leur usage des trente derniers jours. Même script pour chaque prospect, paramétré par nom d'entreprise.
exec seed.sh $COMPANYEnvoyez par email ou Slack au prospect son sous-domaine fonctionnel. Il clique. Il fouine. Il le forwarde à son CTO. Quarante-huit autres restent sur le serveur à tarif fixe que vous louez déjà — KSM déduplique leurs pages RAM, BTRFS déduplique leurs blocs disque. Le repos n'a pas de ligne séparée.
https://$CO.demo.your-app.comPromouvoir à l'inscription avec un PATCH. Détruire en cas de fantôme avec un DELETE. La même mécanique /copy alimente les sandboxes par client une fois qu'un prospect convertit — même forme, tier différent.
Un Loom est une démo du produit de quelqu'un d'autre. Une sandbox est une démo avec les données de quelqu'un d'autre. Un environnement fonctionnel avec leur logo et leurs chiffres est quelque chose que les prospects forwardent à leur CFO.
La démo n'est pas un screen-share de 30 minutes. C'est une URL que le prospect peut ouvrir depuis son laptop le mardi et depuis son téléphone le vendredi. Il la montre à un coéquipier. Il la colle dans un fil Slack. Le deal se réchauffe pendant que vous dormez.
Les clouds par-VM facturent les cinquante environnements que quelqu'un les visite ou non. Sur Hoody, les conteneurs au repos 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 est le delta de ce qui a changé, pas une instance entière.
Quand un prospect signe, le même conteneur devient son tenant. PATCH le tier de demo à production, routez son domaine personnalisé. Pas de migration de données, pas d'onboarding neuf, pas de friction « maintenant on va configurer votre vrai compte ».
Les mêmes cinquante environnements. Facture différente, latence différente, histoire de nettoyage différente. Les chiffres ci-dessous viennent du modèle de conteneur Hoody documenté — votre tier serveur et densité spécifiques varieront.
Dyno Heroku Standard-1X ≈ 25 $/mois × 50 ≈ 1 200 $/mois pour cinquante. La tarification bare metal Hoody commence à 29 $/mois ; 49 $/mois illustre un serveur mid-tier hébergeant des dizaines de conteneurs via la densité RAM/BTRFS — pas le tier d'entrée.
Chaque prospect reçoit une version fonctionnelle de votre produit. Pas un Loom. Pas une sandbox. La leur.
Les façons standards dont les équipes remettent aujourd'hui une démo personnalisée à un prospect. Chacune vous facture par environnement, par minute en appel, ou par tournée de « je vous renvoie le lien ».
Arrêtez de faire la démo de votre produit. Commencez à le confier pour une semaine.