Ein Computer. Kein Image.
Vollständige Debian-13-Maschinen, die in Sekunden booten, standardmäßig persistent sind und HTTP nativ sprechen. Jede Linux-Fähigkeit, per URL adressierbar.
Kein Packaging-Artefakt. Eine Maschine, in der du arbeitest.
Ein POST. Vierzehn Live-URLs.
Jeder Hoody-Container kommt mit 14 integrierten HTTP-Diensten. Sobald der Container startet, hast du 14 Live-Endpoints – kein Setup, kein Deployment, kein Kleber.
CONTAINER LEBEN IN PROJEKTEN · EIN POST → 14 HTTP-URLS + EIN SSH-HOST
Nicht mal dasselbe Werkzeug.
Docker und VMs lösten unterschiedliche Probleme. Hoody ist etwas Drittes – ein Computer, den du mit einer URL adressierst.
Docker ist Packaging. Hoody ist Computing.
Docker-Container liefern Software aus. Hoody-Container führen Software aus und persistieren den Computer, auf dem sie läuft – systemd, Dateisystem, Netzwerk-Stack, 14 HTTP-Dienste.
VMs sind Haustiere. Container sind URLs.
VMs setzen SSH und manuelle Konfiguration voraus. Hoody-Container machen jede Fähigkeit über HTTPS zugänglich – eine URL, die dein Team, dein curl und deine KI nativ sprechen.
Ein Kernel, Hunderte Maschinen.
Hypervisor-VMs: 5–20 pro Server. Hoody-Container: Hunderte. Isolation auf Kernel-Ebene mit VM-ähnlichen Grenzen, ohne VM-ähnlichen Overhead.
Docker löste Packaging. Hoody löste Computing.
(Du kannst Docker trotzdem innerhalb eines Hoody-Containers ausführen.)
Kernel-erzwungen. Nicht auf Anwendungsebene.
Jeder Container ist eine Sicherheitsgrenze, keine Prozessgrenze. Ein Ausbruch erfordert einen Kernel-Exploit, keinen Anwendungsfehler.
Eigenes Dateisystem
Container können die Dateien der anderen nicht sehen. Standardmäßig keine gemeinsamen Volumes. Jeder hat sein eigenes Root, sein eigenes /home, sein eigenes /etc.
Eigenes Netzwerk
Eigene IP-Adresse, eigene Routing-Tabelle, eigenes DNS. Container kommunizieren über HTTP-URLs – dasselbe Protokoll, das zwei Computer im Internet nutzen.
Eigene Prozesse
PID-Namespaces stellen sicher, dass ein kompromittierter Container seine Nachbarn weder sehen noch signalisieren kann. Kein kill -9 über die Grenze.
Gehärteter Kernel 7.0.2-hoody
Seccomp-Filter plus eingeschränkte Syscalls. VM-ähnliche Isolation auf Kernel-Ebene. Firecracker-Micro-VMs verfügbar, wenn du noch mehr brauchst.
Bare Metal, das dir wirklich gehört.
Jeder Container läuft auf Hardware, die du vom Marketplace mietest – nicht auf der gemeinsam genutzten Infrastruktur eines Cloud-Anbieters. Kein gemeinsamer Hypervisor, keine störenden Nachbarn, kein Mieter-eines-Mieters. Das Isolationsmodell funktioniert nur, wenn die Maschine darunter dir gehört.
Eingehend + ausgehend. Pro Container.
Jeder Container kommt mit seiner eigenen Firewall. Erlauben oder blockieren nach Port, Protokoll, IP und Quellbereich. Keine gemeinsame Bridge, keine störenden Nachbarn, keine Überraschungen.
Betreibe sie wie Code.
Container wechseln über HTTP zwischen Zuständen. Starten, Pausieren, Fortsetzen, Snapshot, Kopieren, Synchronisieren – jedes Verb ist ein POST.
Wird bereitgestellt
Alle Dienste verfügbar
Im RAM eingefroren, ~1 s Wiederaufnahme
Angehalten, Dateisystem erhalten
Wird dupliziert, neue ID, neue URLs
Diagnostizieren oder löschen
POST/api/v1/containers/CONTAINER_ID/start
POST/api/v1/containers/CONTAINER_ID/stop
POST/api/v1/containers/CONTAINER_ID/force-stop
POST/api/v1/containers/CONTAINER_ID/restart
POST/api/v1/containers/CONTAINER_ID/pause
POST/api/v1/containers/CONTAINER_ID/resume
POST/api/v1/containers/CONTAINER_ID/copy
POST/api/v1/containers/CONTAINER_ID/sync
POST/api/v1/containers/CONTAINER_ID/snapshots
Nach jedem Neustart wieder aktiv.
Container starten nach Server-Boot, nach Wartung und nach Stromausfall automatisch neu. Standardmäßig aktiviert – deine Maschine kommt von selbst zurück.
Klonen. Synchronisieren.
Kopieren erstellt ein unabhängiges Duplikat – neue ID, neuer SSH-Schlüssel, neue URLs, alle bisherigen Snapshots inklusive. Sync zieht Änderungen aus der Quelle. Regionsübergreifendes DR ist CoW-effizient. Eine Entwicklungsumgebung für einen neuen Kollegen in einem POST klonen.
Unendlich viele Container.
KSM und BTRFS teilen die identischen Teile. Du zahlst nur für das, was sich unterscheidet.
Herkömmliche VMs verbrauchen feste Ressourcen, ob du sie nutzt oder nicht. Eine 2-Kern-4GB-VM kostet im Leerlauf genauso viel wie unter Last.
Hoody-Container nutzen KSM (Kernel Samepage Merging) und BTRFS-Deduplizierung, um identische Speicherseiten und Storage-Blöcke zwischen Containern zu teilen. Hundert Container, die dasselbe Basis-Debian ausführen, verbrauchen nicht den 100-fachen Speicher. Sie teilen das Identische und zahlen nur für das Unterschiedliche.
Entwicklungs-Container kosten im Leerlauf fast nichts.
Test-Runner teilen Basis-OS-Speicher mit der Produktion.
Umgebungen sind kein Budgetgespräch.
Ein Container pro Branch wird praktisch, nicht extravagant.
Du rationierst keine Computer. Du startest sie.
Git gab Code Versionskontrolle. Hoody gibt Versionskontrolle für ganze Computer.
1–5 Sekunden zum Erfassen, unabhängig von der Container-Größe. Copy-on-write auf Dateisystemebene – zehn Snapshots eines 50-GB-Containers kosten 50 GB plus die Änderungen, nicht 500 GB. Branchen wie bei git. Unbegrenzt.
BASIS-IMAGES
Nur Basis-OS-Templates – das Image gibt dir die Distribution. hoody_kit und dev_kit fügen die 14 HTTP-Dienste obendrauf hinzu (beide standardmäßig true; setze eines auf false für ein Standard-OS).
Einen für alles starten.
Wenn ein frischer Linux-Computer Sekunden und nahezu null Grenzressourcen kostet, lautet die Frage nicht „Sollten wir einen verwenden?“ – sondern „Warum haben wir nicht noch einen gestartet?“
Entwicklungsumgebungen
Ein frisches Debian in Sekunden mit 14 URLs und einem SSH-Host. Überlebt Neustarts. Das Laptop-Setup deines Teams, standardisiert und von überall zugänglich.
KI-Sandboxes
Jeder Agent bekommt seine eigene. Isolierter Wirkungsbereich für KI-generierten Code. Snapshot vor jedem Durchlauf, in 1 s zurücksetzen, wenn der Agent es zerstört.
Feature-Branches
Einen Container pro PR starten. Die URL teilen. Reviewer können live damit interagieren. KSM hält die Kosten flat, egal wie viele Branches offen sind.
Staging-Klone
Produktion in einem POST in Staging kopieren – neue ID, neue URLs, gleicher Zustand. Regionsübergreifendes Disaster Recovery ist standardmäßig CoW-effizient.
E2E-Tests
Parallele Test-Runner, jeder in seinem eigenen Linux. Echter Browser, echtes Dateisystem, echtes Netzwerk. Keine Mocks, keine gemeinsame Bridge, kein Flake.
Lehre & Demos
Eine URL teilen – Schüler sind im gleichen Terminal. Mehrspieler per Architektur, kein VPN, keine SSH-Schlüssel zu verteilen.
Deine KI spricht bereits HTTP.
Hoody-Container sprechen HTTP. Die Integration ist das Protokoll – kein SDK zu installieren, kein Adapter, kein Wrapper. Gib dem Agent eine URL und er kann eine Linux-Maschine bedienen.
Die Integration ist das Protokoll. Jeder Agent, der HTTP spricht, kann SSH, Dateien lesen, Befehle ausführen, SQLite abfragen, den Browser steuern – jede Fähigkeit ist ein Endpoint.
Von deinem Host isoliert. Snapshot vor jedem Tool-Aufruf. In 1 Sekunde zurücksetzen, wenn der Agent Unsinn schreibt. Kein Root auf deinem Laptop erforderlich.
Der Agent-Dienst macht die gesamte Fähigkeitsoberfläche des Containers zugänglich. @hoody.com ist eine Skill, die jede KI mit einem Browser aufnehmen kann – null Integrationsarbeit.
Jeder Sub-Agent bekommt seinen eigenen Container. Branchen wie bei git, zusammenführen was funktioniert, verwerfen was nicht. Parallele Arbeit, kein gemeinsamer Zustand, Audit-Trail pro Agent.
Die KI muss deine API nicht lernen. Sie spricht bereits HTTP.
Hör auf, VMs zu mieten. Fang an, Computer zu starten.
Eine Abstraktion. Ein mentales Modell. Ein URL-Muster.
Transparente nutzungsbasierte Preisgestaltung – siehe /pricing.