Jeder Service ist eine URL. Der Proxy ist das Wie.
Ein Container stellt jeden Hoody-Kit-Service unter seiner eigenen HTTPS-URL bereit, plus einen http-PORT-Slug für alles, was du selbst bindest. Ports, Auth, TLS und echte Client-IPs werden alle auf der URL-Ebene aufgelöst.
Der Proxy läuft auf deinem Bare Metal. Hoody sieht Management-API-Aufrufe – Container-Traffic verlässt deinen Server nie.
*.containers.hoody.com — wildcard TLS · no Certificate Transparency log exposure
Eine Grammatik, viele Muster
Jeder Kit-Service wird über denselben Proxy aufgelöst, aber der URL-Slug verrät, was es ist. Dieselbe Grammatik, unterschiedliche Form pro Service.
| Service | URL-Slug | Hinweise |
|---|---|---|
| Workspaces | workspace-N | Kompositions-Schicht über anderen Service-URLs |
| Terminal | terminal-N | Pro-Instanz-Shell; wird auf display-N gemappt |
| Display | display-N | GUI / X11-Desktop pro Instanz |
| Browser | browser-N | Headless Chromium |
| Code | ui · http-PORT | Orchestrator bei ui; VS Code-Instanzen über Ports |
| Dateien | files | Singleton – kein Instanz-Index |
| SQLite | sqlite-N | Ein Slug pro Datenbank-Service |
| Exec | exec-N | Jede Datei im Exec-Verzeichnis wird eine URL |
| Agent | agent-N | AI-Agent mit WebSocket-Streaming |
| cURL | curl-N | Ausgehender HTTP-Proxy |
| Daemon | hoody-daemon-N | Prozess-Supervisor |
| Cron | — (heute per cURL) | Geplante Cron-Jobs |
| Benachrichtigungen | n-N · notification-server-N | Desktop-Benachrichtigungen |
| Pipe | — (über andere Services) | Streaming-Pipes ohne Speicherung |
Projekt 24-Hex × Container 24-Hex = 2^192 Paarkombinationen. Nicht per Brute-Force durchführbar.
Einen Server auf einem beliebigen Port ausführen. Er bekommt eine URL.
http-PORT-Prefixe routen den Proxy zum internen Port deines Containers. Kein nginx Server-Block. Kein Ingress-YAML.
# listening sockets
$ ss -ltnp
https://PROJECT_ID-CONTAINER_ID-http-4000.SERVER.containers.hoody.com
https://PROJECT_ID-CONTAINER_ID-http-5173.SERVER.containers.hoody.com
https://PROJECT_ID-CONTAINER_ID-http-7070.SERVER.containers.hoody.com
— Hoody-Kit-Ports sind für die eigenen Services der Plattform reserviert; alles andere gehört dir. Binde App-seitig jeden Port und expose ihn über http-PORT.
— Apps müssen an 0.0.0.0 binden, nicht localhost – der Socket muss vom Proxy-Container erreichbar sein.
— Proxied HTTP/1.1, HTTP/2, HTTP/3 und WebSocket durchgehend. Beliebiges Benutzer-UDP wird nicht geroutet – eine dedizierte IPv4 nutzen, wenn UDP benötigt wird.
Auth ist eine JSON-Policy, keine Anwendungs-Middleware.
Der Proxy validiert JWT-Claims, Passwort-Hashes, IP-CIDR-Bereiche und Bearer-Tokens, bevor eine Anfrage deinen Container erreicht.
{
"enable_proxy": true,
"default": "deny",
"groups": {
"dashboard": {
"type": "jwt",
"algorithm": "HS256",
"source": "header",
"key": "Authorization",
"secret": "<hmac-secret>",
"claims": { "role": ["admin", "viewer"] }
},
"office-only": {
"type": "ip",
"cidrs": ["203.0.113.0/24"]
}
},
"permissions": {
"dashboard": { "http": [4000, 5173] },
"office-only": { "ssh": true, "terminal": true }
}
}JWT
HS256 · RS256 · ES256 · Header / Cookie / Query · Claim-Validierung
Passwort
HTTP Basic · SHA-256 + Salt · URL-einbettbar
IP
IPv4 CIDR-Match · Echte Client-IP auf Socket-Ebene
Bearer-Token
Mehrere Tokens pro Gruppe · API-freundlich
Container-Berechtigungen ersetzen Projekt-Berechtigungen – sie werden nicht zusammengeführt. Beide Bereiche explizit setzen, wenn beide benötigt werden.
Einprägsame URLs statt kryptografischer URLs
Ein API-Aufruf wandelt die Crypto-URL in api.meinesfirma.com um. Let's Encrypt stellt in 30–60 Sekunden aus und erneuert alle 90 Tage.
https://67e89abc…-890abcdef…-http-4000.node-us.containers.hoody.com
https://api.mycompany.com
Alias-Benennung: 3–61 Zeichen, kleingeschriebene alphanumerische Zeichen plus Bindestriche, muss mit einem Buchstaben oder einer Zahl beginnen und enden.
Was du sonst zusammenflicken würdest
Der Proxy ersetzt einen Stack, den die meisten Teams von Grund auf zusammenbauen: Reverse Proxy + Zert-Manager + VPN oder Tunnel + Pro-App-Auth.
| Concern | Hoody Proxy | Self-hosted Äquivalent |
|---|---|---|
| Wildcard-HTTPS | nativ unterstützt — Native | certbot + Erneuerungs-Cron + Zert-Rotation |
| Routing zum internen Port | nativ unterstützt — Native | nginx Server-Block pro Service |
| Echte Client-IP | nativ unterstützt — Native | X-Forwarded-For pro App parsen |
| JWT · Basic · IP · Token Auth | nativ unterstützt — Native | Middleware pro App + Session-Bibliotheken |
| Eigene Domain + TLS | nativ unterstützt — Native | Cloudflare / DNS-01 / nginx reload |
| Zentralisiertes Anfrage-Audit | nativ unterstützt — Native | nginx Logs + Log-Shipper + Index |
| Iframe-einbettbare URLs | nativ unterstützt — Native | Manuelles CORS / CSP / TLS pro App |
| Läuft auf deiner Hardware | nativ unterstützt — Native | Du betreibst es sowieso selbst |
Wenn du bereits Kubernetes mit einem Ingress-Controller, Cloudflare Tunnels oder Tailscale nutzt, verwende diese weiterhin. Der Proxy richtet sich an Teams, die diese Ebene noch aufbauen oder vereinfachen wollen.
Sechs Workflows, die das URL-First-Modell trivial macht
Aus Mustern, die Teams tatsächlich mit dem Hoody Proxy implementieren.
Eine API ohne Reverse Proxy ausliefern
An 0.0.0.0:4000 binden. http-4000.SERVER.containers.hoody.com erhalten. nginx, Zert und DNS-Lied überspringen.
Eigene Domain mit Auto-TLS
POST /api/v1/proxy-aliases, set a CNAME, and the first request provisions Let's Encrypt in 30–60 seconds.
Blau/Grün via Alias-Tausch
api.firma.com auf Container B zeigen, testen, Alias zurückswappen. Kein Config-Reload, keine Ausfallzeit.
Einem KI-Agenten einen Container zum Steuern geben
Agent bekommt ein JWT, Proxy validiert pro Anfrage, Agent schreibt Dateien, führt Befehle aus, fragt SQLite über HTTPS ab.
Multi-Tenant SaaS-Subdomains
Ein Container pro Mieter; Alias MIETER.deineapp.com. Mieter-Isolation auf der URL-Ebene erzwungen.
Sofortiger Widerruf
Ein DELETE-Aufruf an die Control Plane und die URL ist innerhalb einer Sekunde tot. Kein Cache-Poisoning.
Deine erste URL ist einen API-Aufruf entfernt.
Ein Projekt erstellen, einen Container erstellen, und jeder Service ist bereits online. Keine Infrastruktur zuerst aufbauen.
Siehe auch — /platform/control-plane für Proxy-Alias-, Berechtigungs- und Log-APIs.