How Startpod works
Learn how Startpod provides code execution, a development server, and live previews without remote cloud sandbox infrastructure.
Startpod gives your application a local execution environment called a pod. It combines a virtual filesystem, package installation, process workers, development-server routing, and live previews behind a JavaScript API.
From cloud sandbox to browser pod
A cloud sandbox runs the project on remote compute. Your application waits for that environment to start, connects to it over a network, pays for its running time, and operates the infrastructure around it.
Startpod keeps the developer workflow but runs supported projects in the user's browser:
| Your application needs | Cloud sandbox | Startpod |
|---|---|---|
| Code execution | Runs on remote compute | Runs locally in browser workers |
| Development server | Exposes a remote port or tunnel | Routes requests inside the browser |
| Live preview | Loads through a remote URL or proxy | Loads from the pod's preview URL |
This is a change in infrastructure, not a removal of the developer environment. Your product still needs code execution, a development server, and sometimes a preview. It may not need remote compute, network tunnels, sandbox scheduling, or the operations that support them.
What stays in the browser
Project files, package installation, process execution, development-server requests, and previews stay in the user's browser. A normal edit-and-preview loop does not require a cloud sandbox.
Your application can still provide server routes for work that must remain remote, such as handling secrets or fetching from an upstream that blocks browser CORS requests. Startpod removes unnecessary remote development infrastructure; it does not force every part of your product into the browser.
What you provide
A Startpod integration has two parts:
- Your host application uses the Startpod integration for its framework.
- Your client code boots Startpod and connects it to your editor, terminal, and preview UI.
Startpod intentionally does not prescribe those UI components. The same pod can sit behind a focused tutorial, a full IDE, or an agent workspace.
The pod lifecycle
Boot the pod
Call Startpod.init() once for the page. Startpod loads its packaged runtime.
Mount or restore a project
Add files with mount(), import an archive, or restore a saved project from
IndexedDB.
Run commands
Call spawn() and consume the returned input, output, and exit streams.
Connect the preview
Call mountPreview() with the element where the live preview should render.
Tear down the pod
Call teardown() before leaving the workspace or booting another pod on the
same page.
Where to go next
- Follow the quickstart for the shortest working path.
- Read browser requirements before choosing deployment infrastructure.
- Check compatibility before promising support for a framework or command.