use-cases / recurring-webhook-replay / hero

CRON · FILES · EXEC

Spiele die Webhooks von heute Morgen morgen zur gleichen Zeit erneut ab

Richte deinen echten Stripe-Webhook für 30 Minuten auf eine hoody-files-URL. Das Verzeichnis enthält jetzt 14 JSON-Dateien — jedes Payload, das Production getroffen hat, byteweise. Ein Cron-Eintrag startet ein Exec-Skript, das sie um 9 Uhr von Montag bis Freitag wieder gegen Staging POSTet. Der Schedule läuft nächsten Samstag ab und löscht sich selbst.

Cron API lesen

files.containers.hoody.com · 2026-05-03

https://files.containers.hoody.com/webhooks/2026-05-03live · fs

/ webhooks / 2026-05-0314 Dateien · 33.6 KB

stripe-08-04-11.json2.1 KB
intercom-08-09-44.json1.4 KB
stripe-08-12-02.json2.0 KB
stripe-08-15-22.json2.3 KB
intercom-08-19-01.json1.7 KB
github-08-22-30.json4.8 KB
stripe-08-25-17.json2.2 KB
intercom-08-32-11.json1.5 KB
github-08-37-49.json5.1 KB
stripe-08-41-05.json2.0 KB

stripe-08-15-22.jsonVorschau

{
  "id": "evt_3OHk8ZJs2k9aXq1vQ",
  "type": "payment_intent.succeeded",
  "created": 1714723522,
  "data": {
    "object": {
      "id": "pi_3OHk8ZJs2k9aXq1v0K7rT4mB",
      "amount": 4900,
      "currency": "usd",
      "status": "succeeded"
    }
  }
}

0 8-18 * * * bash /scripts/replay.sh /webhooks/2026-05-03nächste Wiederholung in 14m 22s

von deinem echten Webhook erfasst · von einem Cron-Eintrag wiederholt

use-cases / recurring-webhook-replay / pipeline

Einmal erfassen, als Dateien persistieren, nach Schedule wiederholen

Der gesamte Flow sind drei URLs. Production-Traffic kommt auf der Capture-URL an. Dateien landen in hoody-files. Cron läuft durch den Ordner und POSTet die Bodies wieder gegen Staging. Es gibt keinen Broker, keine Queue, keinen Replay-Service — nur ein Verzeichnis und einen Schedule.

PIPELINEkein Broker · keine Queue

01 · CAPTURE

Production-Webhook wird zum PUT

Setze deine Stripe / Intercom / GitHub-Webhook-URL auf einen hoody-files-Pfad. Jedes Event kommt als PUT an und landet als JSON-Datei, benannt mit seinem Zeitstempel. Das Verzeichnis ist die Aufnahme.

02 · PERSIST

Ein Ordner pro Tag, adressierbar als URL

Dateien persistieren auf der Disk; jede Datei hat ihre eigene URL. Durchsuche das Verzeichnis im Browser, liste es via API oder shell mit curl rein. Die Aufnahme ist ein Fakt, den du catten, scpen oder versionieren kannst.

03 · REPLAY

Ein Cron-Eintrag läuft durch den Ordner

POSTe einen Managed-Cron-Eintrag mit Schedule 0 9 * * 1-5 und Command bash /scripts/replay.sh /webhooks/2026-05-03. Das Skript listet das Verzeichnis und POSTet jede Datei in Zeitstempel-Reihenfolge wieder an Staging.

Capture und Replay sind dasselbe Protokoll an verschiedenen Tagen. Das, was die Bytes aufgenommen hat, ist das, was sie wieder abspielt. Es gibt keinen JSONL-Parser, keinen Sidecar, kein Recording-Format, das du lernen musst — Dateien in einem Ordner, in zeitlicher Reihenfolge.

use-cases / recurring-webhook-replay / mechanism

Zwei POSTs und ein Ordner

Capture ist ein PUT pro Webhook-Event. Replay ist ein POST an die Cron-API. Hoody Files hält die Aufnahme; Hoody Cron läuft nach Schedule durch sie; hoody-exec führt das Bash-Skript aus, das das POSTen erledigt. Drei Services, kein Glue dazwischen.

stripe → hoody-files

PUT · capture

# point your real webhook at hoody-files
curl -X PUT \
  https://files.containers.hoody.com/webhooks/2026-05-03/stripe-08-15-22.json \
  --data-binary @-

# 30 minutes later, the directory holds 14 files
HTTP/1.1 201 Created
webhooks/2026-05-03/stripe-08-15-22.json

den Replay planen

POST · Cron-Eintrag

# one cron entry replays the morning at 9am, mon-fri
curl -X POST \
  https://cron.containers.hoody.com/api/v1/cron/users/me/entries \
  -d '["schedule":"0 9 * * 1-5","command":"bash /scripts/replay.sh /webhooks/2026-05-03","expires_at":"2026-05-10T09:00:00Z"]'

HTTP/1.1 201 Created
{ "id":"f0a8", "schedule":"0 9 * * 1-5", "expires_at":"2026-05-10T09:00:00Z" }

Die Capture-Seite läuft einmal an einem Freitagmorgen. Die Replay-Seite läuft jeden Werktag bis nächsten Samstag, wenn das expires_at-Feld des Cron-Eintrags den Schedule löscht. Du hast eine PUT-URL in deine Webhook-Config geschrieben und einen POST in die Cron-API — das ist der gesamte Load-Test.

use-cases / recurring-webhook-replay / powers

Was dir das gibt, was eine Load-Test-Fixture nicht kann

Synthetischer Traffic ist das, was du dir vorgestellt hast, wie der Request aussieht. Erfasster Traffic ist das, was tatsächlich angekommen ist. Gleiche Feldnamen, gleiche Edge Cases, gleiche Überraschungen.

FIDELITY

Echte Payload-Shapes, nicht deine Vermutung

Die Aufnahme erfasst exakt das JSON, das Stripe gesendet hat — inklusive jedes nullable Felds, jedes unerwarteten Event-Typs, jedes customer_id-Formats, das du vergessen hast. Dein Handler trifft auf dieselben Payloads, an denen er gestern gescheitert ist.

TIMING

Gleicher Tageszeit-Druck wie in Production

Die Cron-Expression 0 9 * * 1-5 platziert den Replay zur Stunde, in der deine echten Nutzer das System tatsächlich verwenden. Der Handler unter Test sieht den Morgenrausch gegen die gleichen Caches, die gleichen Cron-Nachbarn, die gleiche laute DB.

REPEATABILITY

Wiederholen, bis der Bug weg ist

Der Ordner ist immutable; der Cron läuft jeden Werktag bis expires_at. Wenn der Handler beim Dienstags-Lauf immer noch bricht, fixt du ihn und lässt den Mittwochs-Lauf es beweisen. Gleicher Input jedes Mal — der Handler ist das Einzige, was sich ändert.

use-cases / recurring-webhook-replay / capacity

Was der Schedule verspricht

Die Zahlen kommen aus der Hoody Cron Managed Entries API und der Standard-Cron-Expression-Spec — nicht aus erfundenen Benchmarks.

FELDER PRO ENTRY5
Standard 5-Feld-Cron-Expression — Minute, Stunde, Tag-des-Monats, Monat, Wochentag. Dieselbe Syntax, die du 1985 verwendet hast, plant 2026 immer noch den Replay.
ENTRIES PRO SEITE200
GET /users/[user]/entries paginiert bis zu 200 Managed Entries auf einmal. 63 Replay-Schedules pro Environment liegen klar im Budget.
POST ZUM ERSTELLEN1
Erstelle den wiederkehrenden Replay mit einem POST /users/me/entries — schedule, command, expires_at. PATCH später, um ihn stummzuschalten; DELETE, um ihn auszumustern; expires_at mustert ihn für dich aus.

Limits gemäß Hoody Cron Managed Entries API: Standard 5-Feld-Cron-Expressions plus @daily / @hourly Macros, Pagination bis zu 200 Entries pro Seite, expires_at ist optional und deaktiviert den Entry automatisch nach Ablauf der Frist.

use-cases / recurring-webhook-replay / punchline

Production-Traffic, einmal aufgenommen, nach Schedule wiederholt.

erfasst · Freitag 08:00wiederholt · Montag bis Freitag 09:00

WIE DER ALTE LOAD-TEST AUSSAHk6-Skript · faker · vermutete Payload-Shapesdeine Vermutung, was Stripe sendet · jedes Quartal neu vermutet

WIE ES JETZT AUSSIEHTPUT files/webhooks/[day] · POST cron/entries 0 9 * * 1-5echte Bytes, die Production getroffen haben · von einem Schedule wiederholt

Cron API lesen

use-cases / recurring-webhook-replay / replaces

Was das ersetzt

Die Standard-Tools zum Wiederholen von Webhook-Traffic — Recorder, Replay-Services, geplante Mocks. Jedes davon ist ein SaaS, ein Sidecar oder ein Skript, das du babysittest. Das hoody-files + hoody-cron-Paar ist nichts davon.

ngrok Webhook-RecordingEin SaaS-Plan, um Requests aufzunehmen, die du auf Disk schreiben könntest
Hookdeck Event-ReplaysEin Event-Routing-Service für das, was nur Dateien in einem Ordner sind
Custom Replay-SkripteGlue, die du einmal schreibst und vergisst, wie du sie planen sollst
Postman Scheduled MocksEin Monitor-Seat, um HTTP an dein eigenes Staging zu feuern
Mocking-Server in Test-EnvsEin zweites Backend, das neben dem echten gepflegt werden muss
Manuelles Webhook-FuzzingDu, sitzend in einem Terminal um 9 Uhr, Payloads pasted

use-cases / recurring-webhook-replay / cta

Erfasse Freitags Traffic. Plane den Replay nächste Woche. Lass den Cron-Eintrag sich selbst ablaufen, wenn das Experiment vorbei ist.

Cron API lesen

use-cases / recurring-webhook-replay / related

Lies die anderen

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.

Containers·Snapshots

Einen Entwickler mit einem einzigen Link onboarden

Eine neue Engineerin fängt am Montag an. Du schickst eine URL. Sie öffnet sie auf irgendeinem Laptop und ist in einem frischen Container, geklont von deinem Developer-Baseline-Snapshot — Code, Dependencies, Env, Seed-Daten, VS Code im Browser. Code schreiben in fünf Minuten, kein Setup.

Snapshots·Containers·Terminal·Files

API-Endpoints, die on-demand entstehen

Ein Wildcard-Exec-Script fängt den Aufruf ab, fragt eine KI, den Handler zu schreiben, führt ihn in einer V8-Sandbox aus und speichert die Route. Der nächste Aufruf ist nativ.

Exec·Agent·Code·Files

Branch-Computer wie Git-Branches

Snapshot eines laufenden Containers — Dateien, Prozesse, Speicher. Wiederherstellung in Sekunden. Fork via /copy. Branching, aber für den gesamten Computer.

Snapshots·Containers

Echtes VS Code auf deinem Handy

Der Code Orchestrator startet eine VS-Code-Instanz im Container und liefert den Editor über eine ganz normale HTTPS-URL aus. Jedes Gerät mit Browser kann sie öffnen. Die Arbeit lebt im Container, nicht auf dem Gerät.

Display·Terminal·Files·Containers+1

KI-Agenten, die andere KI-Agenten starten

Ein Recherche-Agent POSTet an /api/v1/projects/$PID/containers, um einen Child-Container zu starten, und ruft dann dessen Agent-URL auf wie jeden anderen HTTP-Service. Sub-Agenten starten ihre eigenen Sub-Agenten genauso. Kein Orchestrator-Framework, nur URLs.

Agent·Exec·Containers

Eine Sandbox pro Kunde, automatisch

Ein Exec-Skript fängt deinen Signup-Webhook ab, kopiert einen Fresh-Customer-Container und übergibt dem neuen Tenant seine eigene URL. Isolation ist das Betriebssystem, keine tenant_id-Spalte.

Containers·Snapshots·Exec·Files

Aufwachen zu einem fertigen Prototyp

Übergib der KI einen Absatz um Mitternacht. Sie startet eigene Container, macht Snapshots vor riskanten Schritten und postet zum Notification Webhook beim Sonnenaufgang.

Agent·Snapshots·Containers·Browser+2

Notfall-Fix für Production vom Telefon aus

PagerDuty weckt dich auf. Öffne die Terminal-URL auf deinem Telefon. PATCH einen Snapshot von vor dem Bad Deploy. Production ist zurück. Kein Bastion, kein VPN, kein Laptop.

Terminal·Snapshots·Network

Produktions-Logs an eine URL streamen, die jeder per curl lesen kann

Eine Pipe-URL. Bis zu 256 Leser. Drei Engineers verfolgen denselben Vorfall gleichzeitig — ohne Bastion, ohne Datadog-Sitz, ohne Log-Forwarder.

Pipe

Einen Build gleichzeitig an dreißig CI-Worker pushen

Der Build-Container streamt das Tarball mit ?n=30 in einen Pipe-Pfad. Alle dreißig Test-Worker rufen dieselbe URL per curl ab. Bytes laufen einmal durch, fan-out inklusive.

Pipe

Deinem Agent vom Café aus beim Denken zusehen

Dein Agent läuft zu Hause. Du sitzt im Café. Pipe jedes Loop-Event durch Hoody Pipe und rufe denselben Pfad vom Handy per curl ab — der Trace landet Zeichen für Zeichen. Kein SSH, kein Dashboard, kein Upload.

Pipe·Agent

200 GB zwischen Clouds mit zwei curls verschieben

pg_dump | gzip | curl in Frankfurt. curl | gunzip | psql in Singapur. Bytes fließen durch die Pipe — null Disk dazwischen.

Pipe

Schicke einem Teammitglied einen Datenbank-Stand in einer Zeile

pg_dump streamt direkt in dessen psql. Keine Datei hochgeladen, kein Link geteilt, kein Download. Die Pipe leitet die Bytes durch.

Pipe

LLM-Tokens an alles streamen, was HTTP liest

Schritt 3 streamt Tokens mit curl -T -. Schritt 4 ruft denselben Pfad per curl ab. Tokens wandern in Lichtgeschwindigkeit vom Generator zum Consumer. Keine SSE-Plumbing, kein Broker.

Pipe·Agent

Ein Fortschrittsbalken, dem dein Chef zusehen kann, ohne mitzumachen

Hänge ?progress an die Pipe-URL. Wer sie öffnet, bekommt ein Live-HTML-Dashboard — Bytes, Geschwindigkeit, ETA, Status. Bis zu fünfzig Zuschauer, keiner belegt einen Receiver-Slot, keiner berührt den Stream.

Pipe

Das Webhook-Fan-out, das du nicht selbst bauen musstest

Stripe POSTet auf einen Pipe-Pfad mit ?n=12. Zwölf Subscriber rufen die Receiver-URL per curl mit ?n=12 ab. Die Pipe hält das Event, bis alle verbunden sind.

Pipe·Exec

Ein CI-Cache, der nur aus zwei curl-Befehlen besteht

tar | zstd | curl schiebt node_modules in eine Pipe. Zwanzig nachgelagerte Jobs holen es per curl | zstd -d | tar x. Kein S3-Bucket, keine Cache-Action, keine Egress-Rechnung.

Pipe·Containers

Drag-and-Drop-Uploads in dein Skript

hoody-pipe liefert auf jedem Pfad ein Web-Upload-Formular. Zieh eine Datei auf die Seite, dein Skript liest die Bytes aus stdin. Null Upload-Code, kein S3-Bucket, keine Presigned URLs.

Pipe·Exec

Einen Workshop an 200 Zuschauer vom Laptop aus broadcasten

ffmpeg streamt deinen Bildschirm an einen Pipe-Pfad mit ?n=200. Jeder Teilnehmer öffnet die URL per curl im Browser-Tab. Keine Plattform, keine Logins, kein Upload.

Pipe

Inter-Container-IPC ohne Message Broker

Container A schreibt auf einen Pipe-Pfad. Container B liest vom selben Pfad. Backpressure ist die Verbindung. Kein Redis, keine Queue, kein Broker.

Pipe·Containers

Im Zug deinen Agent tailen, gepingt werden, wenn er ankommt

Der Agent streamt seinen Trace an einen Pipe-Pfad, den du vom Handy aus mit curl ziehen kannst. Wenn er fertig ist, ruft sein letzter Schritt hoody-notifications auf, und dein Handy vibriert. Zwei URLs und ein Buzz — kein SDK, keine Client-App, kein Dashboard.

Pipe·Agent·Notifications

Ein Mikrofon über HTTP, in zwei Terminals

ffmpeg nimmt das Mikrofon auf und pipet es an eine URL. Das andere Ende holt sie per curl und gibt das Audio aus. Kein Zoom, kein SDK, kein Signaling-Server.

Pipe

Fünf Agenten, fünf Pipes, ein Urteil

Ein Panel aus fünf Modellen prüft denselben Input. Jedes läuft im eigenen Container und streamt sein Urteil in seinen eigenen Pipe-Pfad. Ein Judge-Prozess holt alle fünf parallel per curl ab und zählt das Ergebnis aus.

Pipe·Agent·Containers

Spiel den Vorfall von heute Morgen für das ganze Team noch einmal ab

Snapshotte die Logs zur Vorfallszeit in hoody-files. Spiele sie über eine Hoody-Pipe-URL mit ?n=8 ab. Acht Engineers holen denselben Pfad per curl ab und sehen die Kaskade im Gleichschritt – das Post-Mortem ist ein synchroner Stream, kein Confluence-Dokument.

Pipe·Files

Das schnellste „schick mir die Datei“, das du je getippt hast

Ein Teammitglied fragt nach einem 4-GB-Dump. Slack lehnt ab, Drive braucht eine Freigabeanfrage. Du tippst curl -T file …; sie tippen curl … > file. Die Bytes wandern direkt zwischen den Festplatten – kein Upload-Balken, kein Link zum Teilen.

Pipe

Betreibe ein lokales LLM und liefere es an deine ganze Flotte aus

Eine GPU betreibt llama.cpp. Ihre Tokens streamen in einen Pipe-Pfad mit ?n=50. Fünfzig Container holen dieselbe URL per curl ab und teilen sich den Stream.

Pipe·Daemon

Ein Live-Metriken-Dashboard ganz ohne Metrik-Backend

Die Monitoring-Schleife jedes Containers schickt eine Metrik per curl an eine Pipe-URL. Das Dashboard ruft dieselbe URL mit ?progress ab und rendert den SSE-Stream.

Pipe

Der Cron-Job, der sich selbst löscht, wenn du fertig bist

POSTe einen verwalteten Cron-Eintrag mit expires_at 48 Stunden in der Zukunft. Der Job läuft nach Plan und entfernt sich danach selbst — keine Erinnerung, kein Cleanup-PR, kein veralteter Eintrag.

Cron

Snapshote den Container direkt vor der nächtlichen Migration

Ein hoody-cron-Eintrag, der um 02:55 UTC feuert, die Snapshots-URL curlt und das Artefakt pre-migration-2026-05-04 nennt. Fünf Minuten später läuft die Migration. Wenn sie funktioniert, liegt der Snapshot ungenutzt herum und kostet nichts. Wenn sie scheitert, stellst du in 30 Sekunden mit einem einzigen PATCH wieder her.

Cron·Snapshots

Eine eigene Crontab für jeden Kunden, automatisch

Jeder Tenant bekommt seinen eigenen Container und seinen eigenen hoody-cron-Service. Kunde A's 9-Uhr-Digest feuert pünktlich, auch wenn Kunde B's Job 40 Minuten hängt — weil sie nicht in derselben Crontab stehen.

Cron·Containers

Einen Agent um 3 Uhr wecken, ihn um 4 Uhr verabschieden

Ein nächtlicher Cron POSTet einen Spawn-Request, der Agent erledigt seine Stunde Arbeit, dann reißt ein zweiter Cron den Container ab. Der Agent existiert nur, wenn es Arbeit für ihn gibt.

Cron·Agent·Containers

Daily Rollups ohne Orchestrator

Rohe Events stapeln sich in einer SQLite-URL. Jede Nacht curlt ein Cron-Eintrag eine Exec-URL, das Skript führt das Rollup-SQL aus und schreibt die Daily-Tabelle zurück. Kein DAG, kein Airflow-Postgres, kein Scheduler-Dashboard.

Cron·SQLite·Exec

Eine crontab pro Branch, mit dem Code deployt

Dein Repo eincheckt `.hoody/crontab`. Das Deploy-Skript PUTet diese Datei an die Cron-API des neuen Containers. Jeder Branch bekommt seinen Container, sein Dateisystem, seinen Zeitplan.

Cron·Containers

On-Call-Eskalation, die mit der Schicht abläuft

POST einen Cron-Eintrag mit expires_at = Schichtende. Wenn die Schicht endet, löscht sich der Eintrag selbst. Der nächste On-Call postet seinen eigenen.

Cron·Notifications

Stündlicher Scrape, tägliches Digest, wöchentliches Archiv — ein Container

Drei Zeilen in einer crontab: stündlicher Browser-Scrape in SQLite, täglicher Exec-Digest, wöchentliches Archiv in Files. Ein 5-$-Container, drei Rhythmen.

Cron·Browser·SQLite·Files

Lass deine Kunden ihren eigenen Cron-Zeitplan mitbringen

Kunden POSTen ihre eigenen 5-Feld-Ausdrücke; ihre crontab lebt isoliert in ihrem Container. Du validierst nicht gegen eine globale Queue.

Cron·Containers

Plane den Agenten, nicht das Skript

Ein 5-Feld-Cron-Eintrag curlt hoody-agent mit einem Prompt, statt ein festes Skript auszuführen. Heute ist der letzte Tag des Monats — der Agent merkt es. Das Datenformat hat sich geändert — der Agent merkt es.

Cron·Agent

Ein Heartbeat für die stillen Jobs

Jeder Cron-Lauf POSTet einen Heartbeat an einen Notifications-Endpoint. Ein zweiter Cron prüft den letzten Heartbeat und alarmiert bei Stille. Die Stille ist der Alarm.

Cron·Notifications

Behalte die letzten 24 Stunden als 24 Snapshots

Ein stündlicher Cron POSTet einen Snapshot, benannt nach der Stunde. Nach 24 Stunden überschreibt jeder neue Snapshot den von gestern zur gleichen Stunde. Die 24-Etagen-Zeitmaschine.

Cron·Snapshots

Bearbeite deine Crontab vom Handy aus, am Flughafen

Öffne die Cron-URL auf deinem Handy am Gate. Tippe auf eine Zeile, ändere ein einzelnes Feld der Cron-Expression, drücke Speichern. PATCH geht durch. Der Job feuert heute Nacht nach dem neuen Schedule. Keine SSH-Session, keine Jump-Box, kein Laptop.

Cron·Terminal

Ein geplanter Digest, der an 200 Postfächer fan-outet

Cron um 9 Uhr POSTet an ein Exec-Skript, das den Digest baut und eine Pipe-URL mit ?n=200 curlt. Zweihundert Empfänger treffen die gleiche URL einmal.

Cron·Exec·Pipe

Den flakigen Job stummschalten, ohne ihn zu verlieren

PATCH /entries/[id] [ enabled: false ]. Der Job bleibt in deiner Crontab und wartet darauf, repariert zu werden. Kein Löschen, kein Neuschreiben, kein Kontextverlust.

Cron

Ein Agent, der die Agenten von gestern benotet

Ein nächtlicher Cron POSTet an den Supervisor-Agenten mit den gestrigen Agent-Traces aus SQLite. Der Supervisor bewertet jeden einzelnen. Cron ist der Supervisor.

Cron·Agent·SQLite

Cleanup-Jobs, die ihren eigenen Ruhestand planen

Das Cleanup-Skript prüft, ob noch etwas zum Aufräumen übrig ist. Wenn das Verzeichnis leer ist, schickt es ein DELETE auf seinen eigenen Cron-Eintrag. Job erledigt, Job verschwunden.

Cron·Files

TLS-Zertifikate ohne SSH-Session erneuern

Wöchentlich per Cron: POST an ein Exec-Skript, das certbot ausführt und das neue Zertifikat per PATCH an den Proxy schickt. Keine Shell-Session, kein Key, kein Jump-Host.

Cron·Exec

Ein wöchentlicher Canary, der versucht, die Produktion zu zerlegen

Sonntag 7 Uhr weckt ein Cron einen Hoody Agent in einem frischen Container gegen einen Snapshot der Produktion. Er fährt die OWASP Top 20 ab, fuzzt die API und schreibt bis 9 Uhr einen Findings-Bericht an eine URL. Container geht in Rente.

Cron·Agent·Browser·Snapshots

Der Hobbyprojekt-Friedhof, den du dir leisten kannst, am Leben zu lassen

Elf halbfertige Side Projects auf Heroku sind elf Dynos zu je 5–7 $. Auf Hoody sind es elf Container auf einer 29-$-Bare-Metal-Box. Idle kostet null, die URL weckt den Container in Millisekunden, und die Schach-Engine, die niemand benutzt, läuft trotzdem.

Containers

Eine Vorschau-Umgebung pro Pull Request, den ganzen Monat

Jeder offene PR bekommt seinen eigenen Klon eines Snapshots. Der Container wacht auf, sobald Reviewer den Link öffnen; idle PRs kosten nichts.

Containers·Snapshots

Ein 12-Produkt-Portfolio von einer einzigen Bare-Metal-Box aus betreiben

Zwölf isolierte Container, jeder ein eigenes SaaS, teilen sich einen 49-$-Server. Die Marge pro Produkt geht von negativ auf richtig schön.

Containers

Schluss mit der Staging-Server-Steuer

Hör auf, ein Duplikat der Produktion zu bezahlen. Snapshot des Prod-Containers, davon bei Bedarf Staging abzweigen, und zurück auf die Disk einfrieren, wenn keiner testet. Drei Umgebungen, eine Maschine, eine Rechnung.

Containers·Snapshots

Vierzig Kundenseiten, eine Miete, ein Dashboard

Jede Kundenseite lebt in ihrem eigenen Container; du rechnest pro Seite ab, du zahlst den Host einmal. Endlich rechnet sich die Mathematik für Agenturen.

Containers·Workspaces

Ersetz die E2B-Rechnung durch das Bare Metal, das du eh schon mietest

Deine Agents mieten keine Compute mehr im Sekundentakt von E2B/Modal/Daytona. Sie nutzen Container auf der Box, die du bereits hast.

Containers·Agent·Exec

Idle-Staging kostet nichts, also wird Staging nicht mehr gelöscht

Staging starb früher, weil es teuer war, es am Leben zu halten. Wenn Idle gratis ist, darf Staging weiterleben — auch das, das ein Teamkollege vor 90 Tagen zuletzt angefasst hat.

Containers·Snapshots

Sandbox pro Kunde im Flotten-Maßstab

Achthundert isolierte Kunden auf drei Bare-Metal-Servern — eine monatliche Pauschalrechnung, kein Meter pro Mandant. Jeder Tenant bekommt einen echten Container mit eigenem Kernel-Namespace, eigenem Dateisystem und eigener URL. Idle-Container kosten nichts zusätzlich zu dem Server, den du eh schon zahlst.

Containers·Snapshots·Exec

Der CI-Cache, der keine S3-Rechnungsposition ist

Cache-Dateien liegen in /files auf der Box, die du eh schon mietest. Worker schicken Tarballs per PUT und GET über HTTP. Kein S3-Bucket, kein Egress, kein dritter Anbieter — die Bytes verlassen die Box nie.

Files·Containers

Fünfzig Demo-Umgebungen für fünfzig Sales Calls

Jeder Interessent bekommt eine echte, isolierte Kopie deines Produkts mit seinen Daten befüllt. Geklont aus einem Snapshot. Eine Woche lang seine.

Containers·Snapshots

Spiele die Webhooks von heute Morgen morgen zur gleichen Zeit erneut ab

Einmal erfassen, als Dateien persistieren, nach Schedule wiederholen

Production-Webhook wird zum PUT

Ein Ordner pro Tag, adressierbar als URL

Ein Cron-Eintrag läuft durch den Ordner

Zwei POSTs und ein Ordner

Was dir das gibt, was eine Load-Test-Fixture nicht kann

Echte Payload-Shapes, nicht deine Vermutung

Gleicher Tageszeit-Druck wie in Production

Wiederholen, bis der Bug weg ist

Was der Schedule verspricht

Was das ersetzt

Lies die anderen

Sechzig Container auf einem Server

Einen Entwickler mit einem einzigen Link onboarden

API-Endpoints, die on-demand entstehen

Branch-Computer wie Git-Branches

Echtes VS Code auf deinem Handy

KI-Agenten, die andere KI-Agenten starten

Eine Sandbox pro Kunde, automatisch

Aufwachen zu einem fertigen Prototyp

Notfall-Fix für Production vom Telefon aus

Produktions-Logs an eine URL streamen, die jeder per curl lesen kann

Einen Build gleichzeitig an dreißig CI-Worker pushen

Deinem Agent vom Café aus beim Denken zusehen

Teile deinen Bildschirm per URL, nicht per Meeting-Einladung

200 GB zwischen Clouds mit zwei curls verschieben

Schicke einem Teammitglied einen Datenbank-Stand in einer Zeile

LLM-Tokens an alles streamen, was HTTP liest

Ein Fortschrittsbalken, dem dein Chef zusehen kann, ohne mitzumachen

Das Webhook-Fan-out, das du nicht selbst bauen musstest

Ein CI-Cache, der nur aus zwei curl-Befehlen besteht

Drag-and-Drop-Uploads in dein Skript

Einen Workshop an 200 Zuschauer vom Laptop aus broadcasten

Inter-Container-IPC ohne Message Broker

Im Zug deinen Agent tailen, gepingt werden, wenn er ankommt

Ein Mikrofon über HTTP, in zwei Terminals

Fünf Agenten, fünf Pipes, ein Urteil

Spiel den Vorfall von heute Morgen für das ganze Team noch einmal ab

Das schnellste „schick mir die Datei“, das du je getippt hast

Betreibe ein lokales LLM und liefere es an deine ganze Flotte aus

Ein Live-Metriken-Dashboard ganz ohne Metrik-Backend

Der Cron-Job, der sich selbst löscht, wenn du fertig bist

Snapshote den Container direkt vor der nächtlichen Migration

Eine eigene Crontab für jeden Kunden, automatisch

Einen Agent um 3 Uhr wecken, ihn um 4 Uhr verabschieden

Daily Rollups ohne Orchestrator

Eine crontab pro Branch, mit dem Code deployt

On-Call-Eskalation, die mit der Schicht abläuft

Stündlicher Scrape, tägliches Digest, wöchentliches Archiv — ein Container

Lass deine Kunden ihren eigenen Cron-Zeitplan mitbringen

Plane den Agenten, nicht das Skript

Ein Heartbeat für die stillen Jobs

Behalte die letzten 24 Stunden als 24 Snapshots

Bearbeite deine Crontab vom Handy aus, am Flughafen

Ein geplanter Digest, der an 200 Postfächer fan-outet

Den flakigen Job stummschalten, ohne ihn zu verlieren

Ein Agent, der die Agenten von gestern benotet

Cleanup-Jobs, die ihren eigenen Ruhestand planen

TLS-Zertifikate ohne SSH-Session erneuern

Ein wöchentlicher Canary, der versucht, die Produktion zu zerlegen

Der Hobbyprojekt-Friedhof, den du dir leisten kannst, am Leben zu lassen

Eine Vorschau-Umgebung pro Pull Request, den ganzen Monat

Ein 12-Produkt-Portfolio von einer einzigen Bare-Metal-Box aus betreiben

Schluss mit der Staging-Server-Steuer

Vierzig Kundenseiten, eine Miete, ein Dashboard

Ersetz die E2B-Rechnung durch das Bare Metal, das du eh schon mietest

Idle-Staging kostet nichts, also wird Staging nicht mehr gelöscht

Sandbox pro Kunde im Flotten-Maßstab

Der CI-Cache, der keine S3-Rechnungsposition ist

Fünfzig Demo-Umgebungen für fünfzig Sales Calls