Iframes as the universal composition primitive.
Every container service — terminal, display, files, code editor, browser, SQLite UI — is an iframe-embeddable HTTPS URL. Dashboards are not built on top of infrastructure; they are assembled from it.
One HTML file + iframes = custom infrastructure UI · no SDK · no postMessage
Don't build a dashboard over your infra. Assemble it from your infra.
Traditional dashboards read the database, poll APIs, render numbers and charts. A Hoody dashboard embeds iframes of the services themselves — live terminals, running displays, file trees you can edit. There's no sync lag because there's nothing to sync.
No polling layer
The dashboard doesn't poll a monitoring endpoint. It embeds the thing being monitored.
Read and act
See a metric spike? Click into the embedded terminal next to it and type `top`. No context switch.
Per-customer, per-project, per-env
Compose dashboards from URLs — any combination is a dashboard.
AI-composable
An LLM can emit HTML with iframe URLs. Custom observability UI, generated on demand.
Change the container. The iframe reflects.
No postMessage. No parent-child protocol. An iframe shows a service URL; the service is updated via the HTTP API; the next request the iframe makes picks up the new state. The iframe and the API are the same container.
App embeds service URL
Parent page drops an iframe pointing at a container service URL into its layout.
App sends a control HTTP request
POST /api/v1/files/upload (or any other API call) — authenticated against the same container.
Iframe pulls fresh state
Auto-refresh, SSE, or user interaction triggers a new request. The new file is visible in the iframe.
No wrapper protocol
Your app never sends postMessage to the iframe. It just updates the container; the iframe sees the change on its next render.
Iframes render on every browser. Every browser is on every device.
An embedded Hoody dashboard works on a phone. On a tablet. On a TV browser. On a smartwatch. On a VR headset's browser. The embeddability property carries through the entire device landscape because the browser does.
The composition primitive is iframe + HTTPS. Both are universal. That's the only reason device parity is automatic.
An LLM can compose a dashboard from container URLs.
Ask an agent 'build me a health-check dashboard for these three containers.' It emits HTML with iframe tags pointing at the terminal, display, and exec URLs you named. The result is a real, live dashboard in one prompt turn.
Agent receives the spec
'I need to monitor three containers: frontend, backend, db. Show the terminal log of each.'
Agent emits HTML
Template with three iframe tags pointing at the correct terminal-1 URLs for each container.
Serve from anywhere
Paste into a static file, a Notion page that allows iframe embeds, or a dedicated Hoody container running http-3000.
Open the URL
Live dashboard. Composed from infrastructure, not from a dashboard product.
Where embeddability hits the browser's limits.
Iframes are a browser primitive. The browser enforces rules on what can and can't be embedded. These are universal constraints, not Hoody-specific — but they matter when you're composing UIs.
X-Frame-Options / CSP
External URLs that set `X-Frame-Options: DENY` or `frame-ancestors 'none'` cannot be embedded. Hoody's own services don't; third-party URLs you embed might.
Mixed content
Embedding an HTTP URL inside an HTTPS page is blocked. Hoody URLs are always HTTPS — works anywhere.
Third-party cookies
Browsers increasingly block third-party cookies. Auth inside embedded iframes may need per-request tokens instead of session cookies.
Third-party storage
localStorage inside an iframe is scoped to the iframe's origin. Cross-iframe state needs to come from the container, not the browser.
Build the dashboard from the infrastructure, not over it.
One HTML file. A handful of iframe tags. Live running containers. That's the full stack.
See also — /platform/os for composition inside Hoody, /kit/workspaces for the Workspace runtime, /methods/multiplayer for shared iframe sessions.