Zum Inhalt springen
use-cases / preview-env-per-pr-cheap / hero
CONTAINERS · SNAPSHOTS · PR PREVIEWS

Eine Preview-Umgebung pro Pull Request, einen ganzen Monat, 30 $

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.

Snapshot-Docs lesen
CRON · GEMERGTE PREVIEWS LÖSCHENeine Zeile, alle 5 Minuten
# Wenn ein PR mergt, droppt der Cron seinen Container.*/5 * * * * curl -X DELETE https://api.hoody.com/api/v1/containers/$MERGED_PR_CID
SNAPSHOT-ABSTAMMUNGeine Base · viele Klone
STAGING-BASEsnap-2026-05-01 · 4.2 GB
COPY-ON-WRITE-PAGES GETEILT30 / 30 Container
use-cases / preview-env-per-pr-cheap / mechanism

Wie aus einem PR eine URL wird

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.

    01
    STEP 01 · EINMALIG

    Den Staging-Container snapshotten

    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.

    02
    STEP 02 · PRO PR

    Den Snapshot beim Push klonen

    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.

    03
    STEP 03 · BEIM MERGE

    Zerstören, wenn der PR schließt

    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.

use-cases / preview-env-per-pr-cheap / api

Die exakten Endpoints, die deine CI aufruft

Drei echte Endpoints aus den Hoody Containers- und Snapshots-APIs. Klemm sie in den GitHub-Actions-Step, den du schon hast.

PREVIEW-ENV · CALL-TABELLEcontainers + snapshots
  • POSTmethod · path
    /api/v1/containers/[staging_id]/snapshots

    Den staging-base-Snapshot erfassen

    Body: [ "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.

  • POSTmethod · path
    /api/v1/projects/[project_id]/containers

    Pro PR einen frischen Container klonen

    Der 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.

  • DELETEmethod · path
    /api/v1/containers/[pr_container_id]

    Die Preview beim PR-Schließen abbauen

    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.

use-cases / preview-env-per-pr-cheap / powers

Was sich ändert, wenn Previews gratis sind

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.

REVIEW-VELOCITY

Reviewer klicken, ziehen nicht

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.

BUDGET

Idle PRs kosten nichts

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.

DESIGN & PRODUKT

Stakeholder steigen in den Loop ein

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.

use-cases / preview-env-per-pr-cheap / compare

Die Dollar-Mathematik, plain

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.

VORHER · VERCEL PREVIEWS, PRO TEAM

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.

VS
NACHHER · HOODY · EINE BARE-METAL-BOX

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.

use-cases / preview-env-per-pr-cheap / punchline

Preview-Umgebungen sind kein Budget-Posten mehr. Sie werden zum Default.

vorher · gedeckelt bei den aktiven 10nachher · eine pro Pull Request
WIE DIE ALTE POLICY AUSSAHnur die lautesten 10 PRs als Previewdie anderen zwanzig bekommen einen Screenshot im Kommentar
WIE ES JETZT AUSSIEHTjeder PR · jeder Diff · jeder Reviewerkein Policy-Doc, kein Ticket, das nach einer Preview fragt
Snapshot-Docs ansehen
use-cases / preview-env-per-pr-cheap / replaces

Was das ersetzt

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.

  • Vercel Preview Environments (Pro / Enterprise)Pro-Seat plus Build-Minuten plus Bandbreite
  • GitHub Codespaces PreviewsPro-Stunden-Abrechnung, egal ob der Reviewer hinschaut oder nicht
  • AWS Fargate Preview TasksvCPU + Memory-Stunden pro Task, plus Data Transfer
  • Render Preview EnvironmentsPro-Environment-Pricing, idle ist nicht kostenlos
  • Heroku Review AppsEin Dyno pro PR, Dyno-Stunden pro Review
  • Netlify Deploy Previews + Build-MinutenBuild-Minuten zählen jeden Push, nicht jeden Review
use-cases / preview-env-per-pr-cheap / cta

Einmal snapshotten. Pro PR klonen. Beim Merge zerstören. Der Reviewer spürt die Naht nie.

Snapshot-Guide lesen
use-cases / preview-env-per-pr-cheap / related

Lies die anderen