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.icu
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.icu
Drag-and-drop panel composition. See /kit/workspaces for the runtime surface.
SSH
ssh.SERVER.containers.hoody.icu
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.icu
https://abc123-def456-display-1.node-us.containers.hoody.icu
https://abc123-def456-files.node-us.containers.hoody.icu
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.icu
https://PROJECT-CONTAINER-workspace-1.SERVER.containers.hoody.icu
— Recipients still need their own auth on each panel (JWT, password, IP). Sharing the workspace URL shares the composition, not the credentials.
ssh hoody.com — the OS in a terminal.
Not every workflow is a browser workflow. Senior developers who live in tmux, vim, and ssh want to reach the same OS without opening a tab. One hostname per server, public-key routing, and a full-fat shell — same state, different surface.
One hostname per server
ssh.SERVER.containers.hoody.icu routes to whichever container your key matches. Add aliases to your ~/.ssh/config and hoody-server-1, hoody-server-2, etc. become short names.
Public-key routing
Upload a public key to the container; ssh presents the matching private key; you land in that container's shell. No username juggling, no shared credentials.
Tmux-native
The same container's terminal over SSH or over the web terminal URL are the same tmux session. Detach from one surface, reattach on the other without losing state.
SFTP + rsync + sshfs
The SSH endpoint also serves SFTP on port 22 — use any file-transfer tool, mount the container's FS locally via sshfs, rsync the delta — all unchanged.
The OS is the URL grammar. ssh is one of its clients. See /methods/access-network for the full access-protocol story.
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.