
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.
Vous expédiez un portefeuille. Deux produits font du chiffre, dix sont assoupis. Sur un cloud par application, vous paieriez les douze. Sur Hoody, cinquante conteneurs s'empilent sur une boîte à 49 $ (l'entrée Hoody commence à 29 $ ; ce portefeuille monte au niveau supérieur pour la place mémoire) — les dix produits silencieux ne coûtent presque rien en plus de ce loyer plat.
twelve apps · one server · one line item on the card
Un produit n'est pas un serveur, c'est environ quatre conteneurs — front-end, back-end, base de données, worker. Douze produits font cinquante conteneurs. Le noyau déduplique les parties ennuyeuses pour que la machine ne s'en aperçoive pas.
Chaque application est une petite stack : un front Next.js, une petite API, un Postgres ou SQLite, un worker. POST quatre conteneurs sur /api/v1/projects/[id]/containers, donnez-leur un project_alias correspondant au produit, terminé. Douze produits, ça fait cinquante conteneurs et quelques pièces de rechange.
Hoody fait tourner les conteneurs sur LXC, pas sur des VM. Kernel Samepage Merging trouve les pages RAM identiques entre conteneurs basés sur la même Debian — cinquante copies de glibc deviennent une. BTRFS copy-on-write fait la même chose pour le disque. Les conteneurs inactifs ne coûtent que leur delta par rapport à la base, pas une machine entière chacun.
Choisissez un Hetzner AX52 depuis le marketplace de serveurs — 64 Go de RAM, 1 To NVMe, 49 $/mois plafond. C'est la facture. L'offre d'entrée Hoody commence à 29 $ ; ce portefeuille monte au niveau supérieur AX52 pour la place mémoire que cinquante conteneurs veulent. Le cinquante-et-unième conteneur ne coûte aucun dollar de plus.
D'après l'API Containers : chaque conteneur rapporte son propre CPU, mémoire, disque et réseau sur /api/v1/containers/[id]/stats. Le fait marketing, c'est que cinquante de ces endpoints stats peuvent ronronner sur un même hôte sans que l'hôte lui-même se plaigne.
Trois choses qui n'ont de sens que lorsqu'un produit inactif est réellement gratuit.
Les conteneurs arrêtés consomment zéro CPU et zéro RAM — leur système de fichiers se contente de reposer sur BTRFS au coût du delta. L'app de journal d'aquarium avec ses douze utilisateurs ne brûle rien. Vous n'avez pas besoin de la tuer pour vous sentir bien.
Les conteneurs sont des namespaces Linux, pas des locataires partagés dans un control plane. Un bug dans mortgage-calc-pro ne peut pas voir la base de données de chord-finder. Pas de colonnes tenant_id, pas de schéma partagé, pas d'incident « ah, ce tenant a explosé ». L'isolation, c'est le noyau.
Quand le onzième produit décolle, vous ne le replatformez pas. PATCH les ressources du conteneur, donnez-lui plus de cœurs, ajoutez un réplica via /copy. Il tournait déjà là où arrivait son trafic — vous avez juste ouvert le robinet.
Découpez la facture serveur de 49 $ par douze produits et vous obtenez environ quatre dollars chacun. Le graphique est ennuyeux à dessein : chaque produit reçoit le même filet de coût, peu importe son revenu.
Les chiffres sont illustratifs pour un hôte de classe Hetzner AX52. Le coût réel par produit dépend des produits que vous réveillez, mais la borne supérieure, c'est la machine — pas le compte.
Le modèle de portefeuille était un tableur de factures. Maintenant, c'est une seule ligne.
Chacune de ces solutions tarifie un produit unique comme une entreprise unique. Un portefeuille de douze paie chaque frais par application douze fois. Le modèle bare-metal vous facture une fois.
Quand l'inactivité est gratuite, l'idée suivante n'est pas une conversation budgétaire — c'est un POST.