Generate & Hosted Pages
A hosted page is a React app written by an AI agent and kept alive in its own container. There is no build and no deploy: the page runs a dev server, so an edit made from chat appears in the open browser within seconds — at the same URL, forever.
Quick experience
The whole loop from the command line — no build, no deploy, one URL throughout.
Run step 3 with the page open in another window: nothing reloads, nothing rebuilds, and the URL never changes.
Generating a page
The agent writes an ordinary Vite React project. A container starts, runs pnpm dev, and the page is reachable. Nothing is compiled, uploaded, or published.
Serving
Each page has its own container and its own dev server. The router maps the URL path to the right one.
Editing a live page
This is the part that replaces "rebuild and redeploy".
The agent edits the source code inside the container. Vite notices, and pushes just the changed module to every browser that has the page open. A page being watched on a wall display updates without anyone reloading it.
When an edit breaks the page
The agent can read the dev server's compile output and the browser's runtime errors, so it sees its own mistakes and fixes them before reporting success.
Idle pages
A page nobody is looking at costs nothing. It stops after 30 minutes and comes back on the next visit.
Security model
Isolation
Edit instructions come from end users, in plain language. So the agent never touches the host.
A malicious or simply confused instruction can corrupt one page's source code — which the same mechanism can then repair. It cannot reach the machine, the other pages, or anything sensitive.
Kernel isolation
Containers run under gVisor (runsc) rather than the normal runtime.
gVisor implements Linux itself, in user space. The container's syscalls are answered by that kernel — the host kernel sits behind it and is never called directly. The container even reports its own kernel version, 4.19.0-gvisor.
The usual way out of a container is a host-kernel bug. Here the host kernel is not the thing on the other side of the syscall boundary, so that class of escape has nothing to aim at.
Shell / data separation
Two modes. A page built from a plain description has no business data to protect. A page wired to real records does — and even then, its source code contains no business data and no credentials.
Only two things are written into the page — the API base URL and the annotation result ID. Everything else is fetched at runtime. Access control lives in the API layer, not in the page, so a leaked URL exposes an empty shell.
Not embeddable by third parties
When the page loads, it asks its parent window for the current user's token, then calls the DreamLake API with it. The token never appears in the page's source code.
If no parent responds — the URL is opened directly, or embedded in someone else's site — the page shows a blank auth-required screen. There is nothing to extract without a live token from a trusted parent.
| Layer | Mechanism | Description |
|---|---|---|
| Outer | frame-ancestors CSP | A response header restricts embedding to *.dreamlake.ai — the browser rejects third-party embeds before any JavaScript runs |
| Middle | Origin allowlist | The console's token responder only replies to requests from trusted origins, so a page embedded elsewhere never receives a token |
| Inner | API JWT auth | Every API call carries the user's JWT; the server verifies it and enforces namespace access control — the same rules as everywhere else in DreamLake |