Three ways to run a live preview in the browser

When an AI writes an app for you, the moment that matters is not the code appearing. It is the moment you click a button in your own app and it works. Everything before that is a promise; that click is proof.

On Summon.dev I own that moment. A user describes a product, the model builds it, and within seconds they need to see it running in a browser tab — then a developer they summon needs to open a terminal and an editor against the same running app. Getting from “the code exists” to “the app is running in front of you” turned out to be the hardest infrastructure decision in the product, so I tested three very different approaches before we committed. This is what each one is actually good at.

The job to be done

Before comparing tools it helps to be precise about what a preview has to do, because the three options fail in different places:

1. Start fast. A user who just typed an idea will wait a few seconds. They will not wait for a container to be scheduled.
2. Run real code. Node servers, package installs, databases, environment variables. A sandbox that only renders static HTML is a demo, not a preview.
3. Survive edits. The AI regenerates files constantly. The preview has to pick up changes without a cold start each time.
4. Let a human in. On Summon.dev a developer has to be able to open a shell on the same instance the user is looking at.
5. Cost nothing while idle. Most previews are looked at for two minutes and abandoned.

Nobody hits all five. The question is which ones you can live without.

Option one: a real server per preview (Coolify)

Coolify is a self-hosted platform that deploys apps from a git repository or a Dockerfile onto your own servers, with a proper API. The mental model is simple: every preview is a real deployment, with its own container, its own URL and its own logs.

What that buys you is fidelity. Whatever the user’s app needs — a Postgres database, a background worker, a Python service next to the Node one — it runs the way it will run in production, because it is production infrastructure. A developer can docker exec into it and nothing is fake. When the user is finally ready to ship, the preview and the deployment are the same artefact.

What it costs you is the first thirty seconds. Building an image, pulling dependencies and scheduling a container is measured in tens of seconds at best, and every regeneration of the app risks another build. You can mitigate that with warm pools and layer caching, and we did, but you are fighting the tool’s nature. Coolify wants to deploy things; you want to poke at things.

There is also a bill that scales with curiosity. Idle previews hold memory. If a thousand people try your product on launch day, you have a thousand containers to reap, and the reaper is code you now own.

Reach for it when fidelity matters more than the first ten seconds — for example, when the preview is staging.

Option two: run Node inside the visitor’s browser (WebContainers)

WebContainers take the opposite bet: the Node runtime, the file system and the package manager all run inside the browser tab, in WebAssembly. There is no server. The user’s laptop is the preview environment.

The first time you see npm install complete inside a browser tab, without a network round-trip to anything you operate, it is hard not to grin. Startup is nearly instant. Edits are instant, because the AI’s output is written straight into the in-browser file system. Cost per preview is zero, and it scales to any number of users because each one brings their own compute.

The limits show up exactly where the browser’s limits are. The app is sandboxed to what the browser can do: it can serve HTTP to itself, but it cannot open arbitrary sockets, so a real Postgres is out and you end up with SQLite-in-memory shims. Anything native — image processing, sharp, Python — does not exist. Memory is whatever the tab is allowed. And “let a human in” gets strange: the developer’s terminal is talking to a process on the user’s machine, so collaboration means syncing two browsers rather than sharing a server.

There is a licensing consideration too: commercial use needs a commercial agreement, which is fair, but it belongs in the spreadsheet next to the server costs it removes.

Reach for it when the apps you preview are mostly frontend-plus-API, the audience could be large, and the first three seconds decide whether people stay.

Option three: pods on demand (Nodepod)

The third approach sits between the two: a lightweight, purpose-built environment per preview that starts in a second or two, runs real Node with a real file system, and is thrown away when the tab closes. Nodepod is one implementation of this idea; the pattern is what matters — you will find it under several names.

The appeal is that it takes the good half of each of the other options. It is a real process on a real machine, so a database and a shell are normal. It is not a full deployment, so startup is fast and idle cost is small. Regenerated files are written into a running environment rather than rebuilt into an image.

The catch is that the middle of the road has less signage. You are relying on a younger, more specialised tool for the part of your product that has to work every time, and when it misbehaves the community you can ask is small. The isolation guarantees are also weaker than a full container per user, which is fine for previews and not fine for anything that touches other customers’ data — so you have to be honest about which one you are building.

Reach for it when you need a real process and a shell, but a full deployment per preview is too slow or too expensive.

How I would decide today

Line the five jobs up against the three options and the pattern is clear:

	Coolify	WebContainers	Nodepod-style
Starts fast	✗	✓✓	✓
Runs real code	✓✓	partial	✓
Survives edits	partial	✓✓	✓
Lets a human in	✓✓	awkward	✓
Free while idle	✗	✓✓	✓

The mistake I see teams make is picking on fidelity alone, because it is the easiest thing to demo to yourself. Fidelity is what you notice. Speed is what the user notices. If the preview takes twenty seconds, most people never find out how faithful it was.

The second mistake is treating this as one decision. It isn’t. The right answer for the first sixty seconds of a session — before a user has decided to care — is often different from the right answer once they have summoned a developer and are two hours in. Design the boundary between those phases deliberately, and you can start with the fastest option and hand off to the most faithful one without the user noticing the seam.

If you are building something in this space and want a second opinion on where that seam should go, tell me what you’re building. It is the conversation I most enjoy having.