
Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Snapshote deinen Staging-Container einmal. Jeder neue PR klont den Snapshot in seinen eigenen Container mit eigener URL. Der Container wacht auf, sobald ein Reviewer den Link öffnet, döst, wenn niemand zuschaut, und wird per einzeiligem Cron zerstört, sobald der PR schließt. Sechzig Branches, sechzig URLs, eine flache Rechnung.
die URL rechts ist die Preview-Env — ein Klick, echter Container, echte Datenbank
Drei Calls. Eine Cron-Zeile. Die CI-Pipeline, die du schon hast, triggert sie in genau der Reihenfolge, die du dir selbst überlegt hättest.
Wähle den Container, der deinen Staging-Stack betreibt — App, Datenbank, Queues, Fixtures. POSTe einen Snapshot, nenn ihn staging-base. Dateien, Prozesse und Speicher werden eingefangen. Der Snapshot ist ein delta-fähiger Ausgangspunkt, kein Tarball — Klone teilen sich seine Pages, statt sie zu kopieren.
Deine CI bekommt das GitHub-Push-Webhook und POSTet an die Containers-API mit source_snapshot=staging-base. Ein neuer Container bootet in Sekunden mit der geseedeten Datenbank und ausgechecktem PR-Branch. Die URL geht als Status Check zurück.
Ein 5-Minuten-Cron-Eintrag läuft die gemergten PRs durch und DELETEt ihre Container — oder dein Merge-Webhook erledigt das inline. Das Disk-Delta des Containers wird zurückgewonnen, die URL freigegeben, und der Container-Slot wandert für den nächsten PR zurück in den Pool.
Step 02 dauert ungefähr so lange wie ein yarn install. Step 03 ist ein einziger HTTP-Call. Sonst muss niemand wissen, dass der Container des PRs überhaupt existiert hat.
Drei echte Endpoints aus den Hoody Containers- und Snapshots-APIs. Klemm sie in den GitHub-Actions-Step, den du schon hast.
/api/v1/containers/[staging_id]/snapshotsBody: [ "alias": "staging-base", "expiry": 30 ]. Liefert einen Snapshot-Namen wie snap-20260501-093000. Einmal pro Main-Branch-Deploy ausführen — jeder PR-Klon stammt vom jüngsten Capture ab.
/api/v1/projects/[project_id]/containersDer Body wählt server_id und ein container_image; übergib environment_vars, um PR-Nummer, Branch-Ref und Datenbankname einzuschleusen. Der Container bootet vom Dateisystem deines Snapshots, nicht von null — Caches und Seed-Daten sind schon da.
/api/v1/containers/[pr_container_id]Ein Call. Der Container fährt runter und sein Disk-Delta wird zurückgewonnen; sonst muss nichts abgebaut werden. Ein Cron-Eintrag im 5-Minuten-Takt kümmert sich um die PRs, die schlossen, während keiner zugesehen hat.
Endpoints aus der Hoody Container Snapshots API und Containers API. Snapshot-Expiry läuft in Tagen; Container-Erstellung akzeptiert environment_vars, ssh_public_key, autostart, ramdisk und realm_ids — siehe die Docs für das vollständige Request-Schema.
Die Mathematik gatet das Reviewer-Verhalten nicht mehr. Drei Gewohnheiten, die bei 40 $ pro Preview zu teuer waren, tauchen von selbst auf, sobald die Pro-PR-Kosten Rundungsfehler sind.
Niemand checkt den Branch lokal aus, um den Bug zu reproduzieren. Sie öffnen die URL, klicken auf das kaputte Ding, lassen einen Screenshot im PR. Der Review-Loop läuft auf dem, was der Code wirklich tut, nicht auf dem, was der Diff andeutet.
Die fünfzig PRs, die gerade niemand reviewt, kosten null CPU und null RAM. Sie teilen sich die Pages des staging-base-Snapshots auf der Disk, sodass selbst ihr Footprint hauptsächlich das Delta ist. Die Rechnung ist durch die Box gedeckelt, nicht durch die Anzahl offener PRs.
Deine Designerin, dein Support-Engineer, dein Sales Lead — jeder mit der URL kann am PR herumstöbern. Die hätten nie git checkout auf einen Branch gemacht. Mit einem Link schauen sie sich die Änderung tatsächlich an, bevor sie landet.
Ein Team mit 30 PRs pro Monat. Die Vorher-Zahl ist die Standard-Preview-Umgebungsrechnung. Die Nachher-Zahl ist eine Hoody-Bare-Metal-Box, in die alle 30 plus dein Staging passen.
480 $/Monat
Pro-Seat-Pro-Pricing plus Build-Minuten plus Bandbreite für ein 6-Engineer-Team mit 30 PR-Deploys im Monat. Die meisten Teams cappen Previews bei den aktiven 10, weil die nächsten 20 echtes Geld kosten.
30 $/Monat
Ein Mid-Tier-Server vom Hoody-Marketplace betreibt Staging plus 30 PR-Klone plus deinen CI-Cache. Die nächsten sechzig kosten 0 $ extra — Copy-on-Write heißt, jeder Klon ist die Pages des Snapshots plus ein Delta.
Vercel-Pro-Listpreis sind 20 $/Seat/Monat plus Usage; Hoody-Bare-Metal-Pricing ist marktplatzgetrieben und beginnt unter 20 $/Monat für Einstiegsklassen. Container-Dichte hängt vom Workload ab — typische Webapps packen Dutzende bis Hunderte; große stateful Services brauchen mehr Spielraum.
Preview-Umgebungen sind kein Budget-Posten mehr. Sie werden zum Default.
Preview-Umgebungs-Produkte rechnen pro Seat, pro Minute oder pro laufendem Container ab. Hoody rechnet pro Server ab — die 30. Preview kostet dasselbe wie die 1.
Einmal snapshotten. Pro PR klonen. Beim Merge zerstören. Der Reviewer spürt die Naht nie.