TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeStream teilen

FürDev Teams

FürDevOps & Infra

ServicesPipe

Warum HoodyHTTP-nativ

Warum HoodyContainer-Ökonomie

TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeStream teilen

FürDev Teams

FürDevOps & Infra

ServicesPipe

Warum HoodyHTTP-nativ

Warum HoodyContainer-Ökonomie

TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeStream teilen

FürDev Teams

FürDevOps & Infra

ServicesPipe

Warum HoodyHTTP-nativ

Warum HoodyContainer-Ökonomie

TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeStream teilen

FürDev Teams

FürDevOps & Infra

ServicesPipe

Warum HoodyHTTP-nativ

Warum HoodyContainer-Ökonomie

Zurück zu Use Cases

use-cases / push-one-build-to-thirty-ci-workers / hero

PIPE · CI-FAN-OUT

Einen Build gleichzeitig an dreißig CI-Worker pushen

Deine Matrix-CI fächert sich über dreißig Test-Runner auf. Jeder davon braucht dasselbe 800-MB-Image. Stream das Tarball mit ?n=30 in einen Pipe-Pfad. Alle dreißig Worker rufen dieselbe URL per curl ab. Die Bytes laufen einmal durch, der Server hält nichts, und keine Registry-Credentials werden rotiert.

Pipe-Docs lesen

builder.ci

1 Sender

# stream the image oncetar c ./image.tar | curl -T - https://pipe.hoody.com/build-12af?n=30

PUT /pipe1× Egress

?n=30ein Stream

ci-fleet

30 Empfänger

alle verbunden

GET /pipe

EIN SENDER LINKS. DREISSIG GET-EMPFÄNGER RECHTS. DIE PIPE WARTET, BIS ALLE LAUSCHEN, DANN LAUFEN DIE BYTES EINMAL HINDURCH.

use-cases / push-one-build-to-thirty-ci-workers / mechanism

Wie aus dreißig curls ein Stream wird

Die Pipe ist ein Fan-out-Router ohne Disk. Der POST des Senders auf /api/v1/pipe/[path]?n=30 blockiert, bis dreißig Empfänger sich mit demselben n auf derselben URL verbinden. Dann fließen die Bytes vom Build-Container direkt zu jedem Runner — gleichzeitig, in der Geschwindigkeit des langsamsten Empfängers.

Drei Schritte. Keine Registry, kein S3, keine Cache-Action.PIPE · ?n=30

Build streamt einmal

tar c | curl -T - https://pipe/.../build?n=30

Der Build-Container pipet das Tarball direkt in curl. Keine Datei geschrieben, keine Registry gepusht.

Pipe wartet auf die Flotte

POST /api/v1/pipe/[path]?n=30

Der Server hält den Sender, bis alle dreißig Empfänger verbinden. Abweichendes n liefert 400. Vorab verbundene Empfänger sind okay.

Alle dreißig ziehen dieselbe URL

curl https://pipe/.../build?n=30 | tar x

Jeder Runner bekommt identische Bytes. Backpressure kommt vom langsamsten Empfänger, nicht von der Bandbreite des Senders.

Nichts persistiert. Nichts wird gecached. Die Pipe vermittelt die Verbindung und tritt dann zurück. Wenn der langsamste Runner fertig ist, ist der Transfer fertig — und die URL ist weg.

use-cases / push-one-build-to-thirty-ci-workers / numbers

Was es die Matrix kostet

Naiv: dreißig Registry-Pulls desselben 800-MB-Tarballs, dreißig kalte Caches, dreißig Netzwerk-Round-Trips. Pipe: ein Egress, ein Transfer, der langsamste Empfänger gibt das Tempo vor.

WALL TIME

12s

Ein Egress mit Linerate. Der langsamste Empfänger bestimmt das Tempo, aber niemand lädt erneut.

EGRESS

1× / Build

Bytes verlassen den Builder einmal, fächern sich an der Pipe auf. Keine S3-GET-Gebühren, keine Docker-Hub-Pulls.

STORAGE

0 Bytes

Die Pipe hält nichts auf Disk. Keine Registry zum Aufräumen, kein Cache-Key zum Invalidieren.

Die Wall-Time-Zahl geht von einer 30-fachen Matrix im selben regionalen Netz wie der Build-Container aus; Cross-Region-Transfers hängen an der Inter-Region-Bandbreite, nicht an der Pipe.

use-cases / push-one-build-to-thirty-ci-workers / powers

Was das Fan-out freischaltet

Sobald der Build eine URL und dreißig curls ist, fällt ein ganzer Stack an CI-Gerüst weg. Kein Artefakt-Storage zum Altern. Keine Registry-Credentials zum Rotieren. Keine Cache-Action zum Debuggen.

Der langsamste Empfänger gibt das Tempo vor

Backpressure ist in die Pipe eingebaut. Die schnellen Worker verschwenden keinen Registry-Round-Trip, um auf den langsamen zu warten — sie warten an der Pipe und trinken dann im selben Tempo. Niemand lädt erneut.

Keine Registry-Credentials zu rotieren

Nichts wird in eine Registry gepusht, also muss sich auch nichts daran authentifizieren. Die URL selbst ist das Credential — kurzlebig, auf einen Transfer beschränkt, evictet, wenn der Build fertig ist.

Keine S3-Rechnung, keine Egress-Überraschung

Bytes verlassen den Builder einmal. Die Pipe broadcastet. Du zahlst einen Egress pro Build statt dreißig Registry-Pulls pro Matrix-Run.

Kein Cache-Key zum Invalidieren

Die Pipe ist pro Build, nicht pro Key. Es gibt keinen GitHub-Actions-Cache, der danebenliegt, kein Buildx-Layer-Mysterium, kein abgestandenes Tarball vom letzten Main.

Funktioniert für jedes Tarball, nicht nur Images

Dasselbe Muster handhabt node_modules, .pnpm-store, target/, den Wheel-Cache, den Dataset-Shard. Was streamt, fächert sich auf.

use-cases / push-one-build-to-thirty-ci-workers / punchline

Ein Sender. Dreißig Empfänger. Null S3-Rechnungen.

Ein 30er-Push, der früher an einem S3-Roundtrip steckengeblieben ist, fließt jetzt durch eine Pipe und einen Single Egress. Niemand downloaded neu. Keine Registry-Credentials rotieren. Die URL verdampft, wenn die Matrix fertig ist.

1 EGRESS
30 EMPFÄNGER
0 STORAGE
0 CREDENTIALS

Pipe-API öffnen

use-cases / push-one-build-to-thirty-ci-workers / replaces

Was das ersetzt

Die Teile, die ein Matrix-CI-Flow normalerweise zusammensetzen muss — Registry, Cache-Action, Mirror, Custom-Upload-Schritt. Die Pipe faltet sie in eine URL.

AWS S3 (Registry-Storage + Egress)30× GET-Gebühren pro Build, Eviction-Policy, IAM-Rolle
GitHub Actions Cache10-GB-Limit, Key-Kollisionen, Scope-pro-Branch
Docker Hub PullsRate-limitiert, kostenpflichtiger Mirror gegen Throttling
npm / pnpm Registry-MirrorSelbst gehostetes Verdaccio nur, um die Public Registry zu umgehen
Custom CI-Cache-ActionBash-Glue, S3-SDK, Expiry-Logik, On-Call wenn's bricht
Buildx Layer-Cache-ExportLayer-Format-Eigenheiten, Cross-Runner-Cache-Misses

use-cases / push-one-build-to-thirty-ci-workers / cta

Hör auf, dasselbe Tarball dreißig Mal zu pushen. Push es einmal. Lass dreißig curls den Stream teilen.

Pipe-API lesen

use-cases / push-one-build-to-thirty-ci-workers / related

Lies die anderen

Sechzig Container auf einem Server

Eine Bare-Metal-Box betreibt Dutzende bis Hunderte Hoody-Container. KSM und BTRFS-Dedup drücken die Grenzkosten fast auf null.

Containers·Snapshots

Entwickler mit einem Link onboarden

Ein neuer Engineer fängt am Montag an. Du schickst eine URL. Er ö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. In fünf Minuten Code schreiben, nicht einrichten.

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

Gib dem Agent um Mitternacht einen Absatz. Er startet eigene Container, snapshotet vor riskanten Schritten und postet bei Sonnenaufgang an deinen Notification-Webhook.

Agent·Snapshots·Containers·Browser+2

Production-Notfallfix vom Handy

PagerDuty weckt dich. Öffne die Terminal-URL auf deinem Handy. PATCH den Snapshot von vor dem schlechten Deploy. Production ist zurück. Keine 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

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 curlt denselben Pfad. Tokens wandern vom Generator zum Consumer mit Leitungsgeschwindigkeit. Kein 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. Der 9-Uhr-Digest von Kunde A läuft pünktlich, auch wenn der Job von Kunde B 40 Minuten hängt — weil sie nicht in derselben Crontab stecken.

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 checkt `.hoody/crontab` ein. 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

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

Du hast 30 Minuten echten Stripe-Traffic in einen hoody-files-Ordner aufgenommen. Ein Cron-Eintrag spielt ihn jeden Werktag um 9 Uhr gegen Staging ab — gleiches Volumen, gleiche Payloads, gleicher Tageszeit-Druck.

Cron·Files·Exec

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

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

Einen Build gleichzeitig an dreißig CI-Worker pushen

Wie aus dreißig curls ein Stream wird

Build streamt einmal

Pipe wartet auf die Flotte

Alle dreißig ziehen dieselbe URL

Was es die Matrix kostet

Was das Fan-out freischaltet

Der langsamste Empfänger gibt das Tempo vor

Keine Registry-Credentials zu rotieren

Keine S3-Rechnung, keine Egress-Überraschung

Kein Cache-Key zum Invalidieren

Funktioniert für jedes Tarball, nicht nur Images

Was das ersetzt

Lies die anderen

Sechzig Container auf einem Server

Entwickler mit einem 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

Production-Notfallfix vom Handy

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

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

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

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

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