Skip to content
Hoody.com

An iframe on Hoody embeds a computer, not a video. Every HTTP service running in a container has its own URL, anything with a URL fits in an iframe, and one page can hold hundreds of them at once.


A common interface for humans, agents, and devices

Section titled “A common interface for humans, agents, and devices”

Computing increasingly involves three kinds of actors that need to talk to each other:

  • Humans work from any device with a browser: phones, tablets, watches, smart glasses, laptops, TVs
  • AI agents execute autonomously, orchestrate systems, and make decisions
  • IoT devices (sensors, cameras, wearables) feed data in and trigger actions

Today they mostly cannot: a phone has no easy way to control a datacenter, an AI cannot reach your desktop, and a smart watch cannot trigger a deployment. Embeddability closes that gap: when everything has a URL, any device can reach any capability, and the phone in your pocket becomes a window into every computer you run.

The browser won, not as a content platform but as the universal computing interface. Every device has one, every browser speaks HTTP, and a browser session is instant, familiar, and multiplayer by default.

When computers are embeddable as URLs, the browser takes on the role of an operating system. The capability lives in the container, and the device only displays it:

Smart Watch → [iframe] → Full Linux Desktop
Phone → [iframe] → VS Code + Terminal + Database
Smart Glasses → [iframe] → Your Entire Infrastructure

An LLM cannot execute anything without real infrastructure; with the four pieces below in place, an agent can execute work instead of only advising on it:

  • Execution environments: real computers to run on
  • Observability: the agent has to see what it controls, through terminal and display iframes
  • A computer per agent: a fresh environment for every experiment, keeping what works
  • Coordination: multiple agents working together over HTTP

The Hoody Agent, Hoody’s flagship interface, is a terminal program: a TUI that runs inside your container. We never wrote a separate browser client for it, and never needed one.

The terminal service runs the Agent and streams it to your browser tab. Open its URL and the full Agent is there: AI chat, live terminals, files, and a display preview, all in one multi-pane view.

https://PROJECT-CONTAINER-agent-1.SERVER.containers.hoody.com

The same program is reachable three ways:

  • Browser: the agent-1 URL streams the TUI straight into the page
  • Any terminal: ssh hoody.com drops you into the hosted Hoody CLI, where hoody agent opens the same interface
  • Your own machine: hoody agent [container] from the Hoody CLI
Screenshot Coming Soon Hoody Agent: multi-pane TUI in a browser tab: AI chat beside live terminals, files, and a display preview
The Hoody Agent: one terminal program, delivered everywhere as a URL

The Agent that manages your containers runs in a container itself and reaches you the way every other program does: as a URL. Any HTTP service you run in a container gets an HTTPS URL, with HTTP/2 and HTTP/3, automatic certificates, and nothing to configure, so anything you run that speaks HTTP can be embedded the same way: a Jupyter notebook, a game server dashboard, a custom admin panel, an AI agent’s workspace. For a live example, the terminal further down this page is a real container embedded with a plain <iframe>.

Hoody OS takes the same idea further. It is a complete multiplayer web-based operating system with floating windows, AI agents, terminals, code editors, file browsers, and display viewers. It took under five days to build, it is production-ready, and Hoody itself runs from it. The build stayed that small because everything in it is embedded:

  • Every window is an iframe to a container service
  • Every tool is embedded via a URL
  • No custom rendering: web standards only
Screenshot Coming Soon Hoody Agent: floating windows showing terminal, code editor, AI chat, and display viewer arranged in a custom layout
Hoody OS: A web-based operating system built on pure embeddability

Hoody OS includes three applications:

  • Hoody Home: dashboard, project launcher, quick access
  • Hoody Console: server management, container administration, monitoring
  • Hoody Agent: a floating-window desktop with drag-and-drop arrangement

Hoody OS itself runs on a Hoody container. The OS that manages your containers is a container, which makes it embeddable, shareable, and multiplayer; you can embed the OS inside another OS. If a program runs on your server, it has a URL, and that URL works everywhere.

You can build your own OS the same way. Because containers, files, terminals, and displays are all HTTP, an AI can orchestrate your entire infrastructure conversationally; Hoody OS itself was built like that.

You do not even need a browser:

Terminal window
ssh hoody.com

You land in the hosted Hoody CLI. There is no username, no password, and no SSH key exchange: it shows a login screen, and you sign in from inside, just as you would in a browser. Run hoody agent and the full Agent opens, with the same AI chat, the same panes, and the same containers, rendered in characters.

Screenshot Coming Soon ssh hoody.com: the hosted Hoody CLI with the Hoody Agent TUI open, AI chat and live panes in pure text characters
ssh hoody.com: your entire environment, from the lightest possible client

Hoody OS renders in the terminal the same way: the same floating windows, AI chat, and file browser, drawn in characters. Any device with an SSH client qualifies:

  • A laptop with no browser
  • A Raspberry Pi over SSH
  • A server in a datacenter
  • Your phone’s terminal app
  • An ESP32: if it can hold an SSH connection, it can run Hoody OS
Screenshot Coming Soon ssh hoody.com: Hoody OS rendered as a TUI, showing floating windows with terminal, AI chat, and file browser in pure text characters
ssh hoody.com: your entire OS, from the lightest possible client

An SSH client is about the least software a device can run. It is still enough to reach the entire environment.


<iframe src="https://dev-abc123-display-1.node-us.containers.hoody.com" />
<iframe src="https://staging-def456-display-1.node-us.containers.hoody.com" />
<iframe src="https://prod-cluster42-display-1.node-us.containers.hoody.com" />
<iframe src="https://ai-agent99-display-1.node-us.containers.hoody.com" />
<iframe src="https://demo-cust231-display-1.node-us.containers.hoody.com" />

Each of those URLs is a running computer, not a mockup and not a remote-desktop product: the iframe shows the live container itself, in your browser. Spawn 1000 containers and you can embed all of them in one page; a dashboard built this way embeds the infrastructure itself rather than a rendering of it.


Each project gets its own set of containers, each container is an iframe, and a single workspace can show them all. One person can run 100 projects and 500 containers from one screen:

  • Project Alpha: 5 iframes (frontend, backend, db, monitoring, docs)
  • Project Beta: 8 iframes (microservices, each in its own container)
  • Project Gamma: 12 iframes (a full Kubernetes simulation, local)
  • AI Experiments: 47 iframes (each AI agent gets its own playground)

Switching projects changes which iframes are visible. Everything keeps running.


There is no postMessage and no parent-child wiring here. The iframes display computers, and those computers are HTTP: change the computer over HTTP and the iframe reflects it. No iframe manipulation is involved, only regular HTTP requests:

// Execute a command in the container displayed in the iframe
const box = await hoody.withContainer(container);
const result = await box.terminal.execution.execute({
command: 'npm run build'
});
// The iframe showing the terminal updates on its own:
// the request changed the computer, and the iframe
// shows whatever the computer is doing.

Because containers are HTTP-native, any change made over HTTP appears in every iframe displaying that container:

  • Deploy code over HTTP and the display iframe shows the new version
  • Execute a terminal command over HTTP and the terminal iframe shows the output
  • Update a file over HTTP and the file browser iframe reflects the change
  • Start a service over HTTP and the monitoring iframe shows it running

The request can come from anywhere: a phone updating an iframe on a TV, an AI agent updating one on a laptop, a smart watch updating one on a tablet, a script updating every iframe everywhere. There is no parent window, no postMessage, and no iframe-specific API; the request goes to the computer, and the iframe is a view of it.


Open your phone’s browser and type a URL: you are looking at computer #473 of your fleet. Swipe left for computer #474, swipe right for computer #472, pinch to see all 1000 as thumbnails. Each one is a full computer, each one is an iframe, and each one is already running.

That makes the whole setup portable. Work from a café in Tokyo, continue from a beach in Bali, pick up mid-conversation on a train in Switzerland. Your AI agents keep working while you travel; they do not pause because you changed locations, and they do not lose context because you switched devices.

Your phone at the airport shows the same environment as your laptop at home: same agents, same conversations, same infrastructure. There is nothing to sync, reconnect, or resume, because everything is already online and reachable from anywhere. The phone did not get more powerful; it displays computers that keep running elsewhere.


An iframe on your laptop, your phone, your TV, or a VR headset shows the same thing: a computer that runs elsewhere and is addressed by URL. The computer is not “here” or “there”; it is reachable from anywhere via its URL.


Embedding a URL takes the place of installing software. The service behind the URL is already deployed and live. Nothing needs an integration layer, because everything speaks HTTP. And when you need another computer, you spawn one; what remains is infrastructure you compose out of iframes.

Next: Security Model →