The operating environment you compose out of URLs.
Every panel is an iframe to a Kit service URL. Your layout is a URL. The OS is built from the grammar itself — not something bolted on top.
Home (entry) · Console (admin) · Workspaces (composition) · SSH (terminal-native)
— workspace-1 is the workspace service, instance 1 — same URL grammar as every other Kit service.
Four ways into the same OS.
Home is where you land. Console is the admin view inside Home. Workspaces is where you compose. SSH is the terminal-native client. Four surfaces, one URL fabric.
Home
https://app.hoody.com
Log in and every project and container you own is there. Not a dashboard — the operating environment itself.
Console
admin views inside Home
Where tokens, wallet, realms, and platform operations live. Same auth as Home; no separate hostname.
Workspaces
workspace-1.SERVER.containers.hoody.com
Drag-and-drop panel composition. See /kit/workspaces for the runtime surface.
SSH
ssh.SERVER.containers.hoody.com
Terminal-native OS client. One hostname per server, routed to the right container by your public key.
Fourteen services are already running inside every container.
The OS isn't empty. Every new container brings up the full Kit — terminal, display, files, code, SQLite, cron, notifications, more — as HTTP services on their own URLs, reachable from every surface.
Interactive
- —Terminal — persistent shell with multiplayer cursors
- —Display — full X11 desktop streamed to the browser
- —Browser — automated Chrome instances you can drive via HTTP
- —Code — VS Code hosted on the container filesystem
Data
- —Files — cloud-backend-aware filesystem API
- —SQLite — HTTP endpoint to a concurrent-safe database
- —Pipe — streaming transfer between containers
- —Exec — scripts-as-HTTP-endpoints (serverless inside your container)
Ops
- —Cron — scheduler with managed entries
- —Daemon — process supervision as HTTP
- —Notifications — push to phone/desktop from any HTTP call
- —cURL — outbound HTTP with schedule + retry + sessions
Intelligence
- —Agent — LLM-powered autonomous worker with MCP client
- —Workspaces — the composition service itself, recursive
Every service is already running. Nothing to install. Hit its URL from any surface — browser, terminal, or an iframe.
A layout is a list of URLs.
The workspace composes Kit service URLs into iframes. Any URL, any container, any server. The OS stays out of the way — you pick what shows up where.
https://abc123-def456-terminal-1.node-us.containers.hoody.com
https://abc123-def456-display-1.node-us.containers.hoody.com
https://abc123-def456-files.node-us.containers.hoody.com
Three panels · three Kit service URLs · three containers. The workspace's only job is to lay them out.
— External URLs that set X-Frame-Options: DENY cannot be embedded in a workspace panel — a browser-level constraint, not Hoody-specific.
Send the URL. See the same view.
Workspace URLs are stable. Paste one into a teammate's browser and they land on the identical composed view — live, multi-container, no screen share.
https://app.hoody.com
https://PROJECT-CONTAINER-workspace-1.SERVER.containers.hoody.com
— Recipients still need their own auth on each panel (JWT, password, IP). Sharing the workspace URL shares the composition, not the credentials.
What a browser + URL grammar replaces.
Desktop OS, cloud IDE, PaaS control panel — each covers part of this. Hoody OS is where the three converge because the underlying primitive is an HTTP URL.
| Concern | Hoody OS | Traditional stack |
|---|---|---|
| Install | Nothing — browser has it already | Download OS · burn ISO · partition · reboot |
| Reach from anywhere | Open the URL on any device | VPN · RDP · TeamViewer · remote desktop clients |
| Share an environment | Paste the workspace URL | Screen share · Zoom · pair-programming plugin |
| Admin surface | Console (same auth as Home) | SSH + config files · kubectl · custom panel |
| Compose services | Drag-drop iframes onto a workspace | tmux + window manager · Electron shells · hand-rolled dashboards |
| Device support | Any browser + any SSH client | Per-OS clients · per-device installers · sync conflicts |
Traditional desktop OSes are great when you want a local machine. Hoody OS is better when the 'machine' is a moving target across phones, tablets, TVs, and remote workstations you don't own.
Your OS is already running.
Log in at Home. Open a workspace. Arrange panels. The URL at the top of your browser is the composition — send it to anyone.
See also — /kit/workspaces for the Workspace runtime surface, /platform/proxy for the URL grammar underneath, /methods/access-network for SSH + device parity, /methods/multiplayer for live shared sessions.