TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeMulti-Tenant SaaS

FürSolo Founder

FürDev Teams

FürAgenturen

ServicesContainers

ServicesSnapshots

ServicesExec

ServicesFiles

Warum HoodyContainer-Ökonomie

Warum HoodyBare-Metal-Isolierung

Warum HoodySnapshot-Zeitreisen

BrancheSaaS

TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeMulti-Tenant SaaS

FürSolo Founder

FürDev Teams

FürAgenturen

ServicesContainers

ServicesSnapshots

ServicesExec

ServicesFiles

Warum HoodyContainer-Ökonomie

Warum HoodyBare-Metal-Isolierung

Warum HoodySnapshot-Zeitreisen

BrancheSaaS

TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeMulti-Tenant SaaS

FürSolo Founder

FürDev Teams

FürAgenturen

ServicesContainers

ServicesSnapshots

ServicesExec

ServicesFiles

Warum HoodyContainer-Ökonomie

Warum HoodyBare-Metal-Isolierung

Warum HoodySnapshot-Zeitreisen

BrancheSaaS

TypFreigeschaltet

PhaseFleet

SchwierigkeitMittel

AufgabeMulti-Tenant SaaS

FürSolo Founder

FürDev Teams

FürAgenturen

ServicesContainers

ServicesSnapshots

ServicesExec

ServicesFiles

Warum HoodyContainer-Ökonomie

Warum HoodyBare-Metal-Isolierung

Warum HoodySnapshot-Zeitreisen

BrancheSaaS

Zurück zu Use Cases

use-cases / one-sandbox-per-customer / hero

CONTAINER · MULTI-TENANT-SAAS

Ein Sandbox pro Customer, automatisch

Hör auf, tenant_id in jede Tabelle zu streuen. Wenn sich ein Kunde anmeldet, kopiert ein Exec-Skript einen Fresh-Customer-Container und übergibt ihnen ihre eigene URL, ihr eigenes Dateisystem, ihre eigene SQLite. Isolation ist das Betriebssystem zwischen ihnen, nicht eine WHERE-Klausel.

Copy-Dokumentation lesen

SIGNUP-WEBHOOK → CONTAINER STARTEN

DEIN WEBHOOK HANDLER

POST

# ausgelöst von Stripe checkout.session.completed

POST /api/v1/projects/{id}/containers

Authorization: Bearer hdy_***

{

"user_id": "usr_7xk9",

"container_image": "ubuntu/24.04",

"name": "sbx-usr-7xk9",

"hoody_kit": true

}

HOODY API · ANTWORT

201 Created

{

"id": "ctr_a9f3e2b1c7d04500",

"status": "provisioning",

"name": "sbx-usr-7xk9",

"url": "https://proj-ctr_a9f3...containers.hoody.com"

}

Wenn ein User sich registriert, passiert genau das.

use-cases / one-sandbox-per-customer / trigger

Was dieser eine API-Call provisioniert

Jeder POST auf /api/v1/projects/{id}/containers startet eine isolierte Umgebung. Ein Call, ein Tenant, eine URL zurück an deine App.

01 · WEBHOOK

Signup löst den Container-POST aus

Dein Stripe-Webhook (oder ein beliebiger Billing-Webhook) trifft auf ein Hoody Exec Script. Kein Express, keine Server-Config — nur eine Datei in scripts/.

02 · ISOLATION

Linux-Namespaces, keine WHERE-Klausel

Der neue Container hat sein eigenes Dateisystem, sein eigenes SQLite, seine eigene Ramdisk. Tenant A kann die Daten von Tenant B schlicht nicht sehen.

03 · URL

Eine eindeutige URL zurück zu deiner App

Die Antwort enthält eine Container-URL. Deine App leitet den User in seine eigene Sandbox — im selben Deploy-Fenster.

04 · FIREWALL

Netzwerkregeln pro Tenant geklont

Netzwerk- und Firewall-Regeln des Containers werden aus deinem Template kopiert. Jeder neue Tenant startet von derselben Security-Baseline.

05 · IDLE

Null Kosten im Leerlauf

Stopp den Container und er kostet nichts. BTRFS speichert nur das Delta zu deinem Template — Speicher bleibt günstig, selbst im großen Maßstab.

06 · OFFBOARD

DELETE Container = Tenant vergessen

Ein DELETE-Call entfernt den Container und alle zugehörigen Daten. DSGVO-Offboarding ist kein Script, sondern ein einziger HTTP-Call.

Der ganze Flow ist ein Webhook-Handler. Kein Kubernetes-Operator, kein Namespace-YAML, kein Cluster-Admin. Drei HTTP-Calls: Webhook rein, Container raus, URL zum User.

use-cases / one-sandbox-per-customer / compare

Geteilte Multi-Tenancy vs. Container pro Kunde

Die traditionellen Optionen waren entweder eine Spalte auf jeder Tabelle oder eine Flotte aus VMs, die du dir nicht leisten konntest. Hoody ist eine dritte Form: Container, billig genug, um jedem Kunden einen zu geben.

DIMENSION

GETEILTE DB · TENANT_ID

HOODY · CONTAINER PRO KUNDE

ISOLATIONWHERE tenant_id = $1 — und du hoffst, dass jede Query daran denktLinux-Namespaces. Tenant A kann das Filesystem von Tenant B buchstäblich nicht sehen.
DATA-LEAK-OBERFLÄCHEjeder JOIN, jeder ORM-Hook, jedes Reporting-Skriptdie Container-Grenze. Ein Artefakt zu auditen, nicht 200 Query-Stellen.
PER-TENANT-CONFIGFeature-Flags-Tabelle, brüchig, halb getestet in DevEdit der Environment eines Containers. Die anderen 399 bleiben unverändert.
NOISY NEIGHBORein heavy Customer kann die geteilte DB blockenContainer-CPU- und Disk-Quotas; die Last eines Tenants bleibt in seiner Box.
OFFBOARDINGDELETE … WHERE tenant_id … plus 12 weitere Tabellen, die du vergessen hastDELETE den Container. Ihre Daten gehen mit. GDPR ist ein HTTP-Call.
KOSTEN IM IDLEjede Zeile kostet Storage, auch wenn der Kunde schläftstoppe den Container — null CPU, null RAM. BTRFS behält nur das Delta.

keine tenant_id-Spalten
keine Row-Level-Security-Audits
kein Namespace-YAML
delete = vergessen

use-cases / one-sandbox-per-customer / punchline

Multi-Tenancy ist kein Architekturproblem mehr. Es wird zu einem `cp`-Befehl.

ONBOARDPOST /containers/$TEMPLATE/copy

OFFBOARDDELETE /containers/$CID

PER-TENANT-TWEAKPATCH /containers/$CID [ env_vars ]

Namespace-Grade-Isolation
GDPR-Delete in einem Call
ein Container pro Account

use-cases / one-sandbox-per-customer / replaces

Was das ersetzt

Per-Tenant-Isolation hat historisch entweder eine clevere WHERE-Klausel oder ein teures Cluster bedeutet. Container pro Kunde verdrängt die üblichen Workarounds:

Geteilte Multi-Tenancy (tenant_id-Spalte)Eine schlechte Query legt alle offen
Eigene Tenant-Isolation-MiddlewareSelbstgebaute Guard, die du für immer pflegst
Postgres-Row-Level-Security-PoliciesRichtige Antwort, teuer pro Tabelle zu auditen
Kubernetes-Namespace pro TenantCluster-Level-Overhead, Ops-Team nötig
Per-Customer-Schemas / DatenbankenMigrations-Multiplikator, Connection-Pool-Schmerz
Stripe-Metering-Zeilen in einer geteilten TabelleUsage-Tracking auf dieselbe geteilte Box geklebt

use-cases / one-sandbox-per-customer / cta

Idle Customers kosten nichts. Aktive skalieren on demand. Das Ganze läuft auf $49 Bare Metal, bis du Hunderte zahlende User hast.

Container-Copy-Docs lesen

use-cases / one-sandbox-per-customer / 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

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

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

Ein Sandbox pro Customer, automatisch

Was dieser eine API-Call provisioniert

Signup löst den Container-POST aus

Linux-Namespaces, keine WHERE-Klausel

Eine eindeutige URL zurück zu deiner App

Netzwerkregeln pro Tenant geklont

Null Kosten im Leerlauf

DELETE Container = Tenant vergessen

Geteilte Multi-Tenancy vs. Container pro Kunde

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

Aufwachen zu einem fertigen Prototyp

Production-Notfallfix vom Handy

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

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