
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.
Faites un snapshot de votre conteneur de staging une fois. Chaque nouvelle PR clone le snapshot dans son propre conteneur avec sa propre URL. Le conteneur se réveille quand un relecteur ouvre le lien, fait la sieste quand personne ne regarde, et se fait détruire par une ligne de cron quand la PR se ferme. Soixante branches, soixante URL, et une facture stable.
l'URL à droite, c'est l'env de preview — un clic, vrai conteneur, vraie base de données
Trois appels. Une ligne de cron. Le pipeline de CI que vous avez déjà les déclenche dans l'ordre que vous écririez vous-même si vous deviez le faire.
Choisissez le conteneur qui fait tourner votre stack de staging — application, base de données, files, fixtures. Faites un POST de snapshot, nommez-le staging-base. Fichiers, processus et mémoire sont capturés. Le snapshot est un point de départ delta-able, pas un tarball — les clones partagent ses pages au lieu de les copier.
Votre CI reçoit le webhook de push GitHub et fait un POST à l'API conteneurs avec source_snapshot=staging-base. Un nouveau conteneur démarre en quelques secondes avec la base de données pré-remplie et la branche de la PR sortie. L'URL revient comme status check.
Une entrée cron de 5 minutes parcourt les PR fusionnées et fait DELETE sur leurs conteneurs — ou votre webhook de fusion le fait en ligne. Le delta disque du conteneur est récupéré, l'URL est libérée, et le slot retourne au pool pour la prochaine PR.
L'étape 02 prend à peu près le temps d'un yarn install. L'étape 03 est un seul appel HTTP. Rien d'autre n'a besoin de savoir que le conteneur de la PR a existé.
Trois vrais endpoints des API Hoody Containers et Snapshots. Glissez-les dans l'étape GitHub Actions que vous avez déjà.
/api/v1/containers/[staging_id]/snapshotsBody : [ "alias": "staging-base", "expiry": 30 ]. Renvoie un nom de snapshot comme snap-20260501-093000. Lancez ceci une fois par déploiement de la branche main — chaque clone de PR descend de la capture la plus récente.
/api/v1/projects/[project_id]/containersLe body choisit server_id et un container_image ; passez environment_vars pour injecter le numéro de PR, la ref de branche et le nom de base de données. Le conteneur démarre depuis le système de fichiers de votre snapshot, pas de zéro — caches et données seed sont déjà là.
/api/v1/containers/[pr_container_id]Un seul appel. Le conteneur s'éteint et son delta disque est récupéré ; rien d'autre n'a besoin d'être démonté. Une entrée cron toutes les 5 minutes gère les PR qui se sont fermées pendant que personne ne regardait.
Endpoints issus de l'API Hoody Container Snapshots et de l'API Containers. L'expiration des snapshots est en jours ; la création de conteneurs accepte environment_vars, ssh_public_key, autostart, ramdisk et realm_ids — voir la doc pour le schéma complet de la requête.
Les calculs cessent de brider le comportement des relecteurs. Trois habitudes qui étaient trop chères à 40 $ la prévisualisation apparaissent d'elles-mêmes dès que le coût par PR est une erreur d'arrondi.
Personne ne checkout la branche en local pour reproduire le bug. Ils ouvrent l'URL, cliquent sur la chose cassée, laissent une capture d'écran dans la PR. La boucle de relecture tourne sur ce que le code fait vraiment, pas ce que le diff suggère qu'il fait.
Les cinquante PR que personne ne relit en ce moment coûtent zéro CPU et zéro RAM. Elles partagent les pages du snapshot staging-base sur le disque, donc même leur empreinte est principalement du delta. La facture est bornée par la machine, pas par le nombre de PR ouvertes.
Votre designer, votre support engineer, votre lead commercial — quiconque a l'URL peut tester la PR. Ils n'allaient jamais git checkout une branche. Avec un lien, ils regardent vraiment le changement avant qu'il ne sorte.
Une équipe ouvrant 30 PR par mois. Le chiffre d'avant est la facture standard d'environnements de prévisualisation. Le chiffre d'après, c'est une seule machine bare-metal Hoody qui accueille les 30 plus votre staging.
480 $/mois
Tarification Pro par siège plus minutes de build plus bande passante sur une équipe de 6 ingénieurs lançant 30 déploiements de PR par mois. La plupart des équipes plafonnent les prévisualisations aux 10 actives parce que les 20 suivantes coûtent vraiment de l'argent.
30 $/mois
Un serveur de gamme moyenne du marketplace Hoody fait tourner staging plus 30 clones de PR plus votre cache CI. Ajoutez les soixante suivants pour 0 $ — le copy-on-write fait que chaque clone est constitué des pages du snapshot plus un delta.
Le tarif public de Vercel Pro est de 20 $/siège/mois plus l'usage ; la tarification d'entrée bare-metal Hoody commence à 29 $/mois et varie selon les spécifications, la région et la durée de location. La densité des conteneurs dépend de la charge — les apps web typiques s'empilent par dizaines à centaines ; les gros services stateful demandent plus de marge.
Les environnements de prévisualisation cessent d'être un poste budgétaire. Ils deviennent la valeur par défaut.
Les produits d'environnements de prévisualisation se tarifent par siège, par minute, ou par conteneur en cours d'exécution. Hoody se tarifie par serveur — la 30e prévisualisation coûte la même chose que la 1re.
Snapshot une fois. Clone par PR. Destruction à la fusion. Le relecteur ne sent jamais la couture.