Live Preview URLs for Agent-Built Apps: How a Sandbox Serves What Your Coding Agent Just Wrote

A sandbox with a live preview URL gives the app your coding agent just built a real, reachable web address: the code runs in its own Firecracker microVM, and anything listening on a port inside that machine gets a public URL you can open in a browser. You click, you see the app, you judge it. No local checkout, no port forwarding, no "works on my machine."

Introduction

Coding agents write apps fast. Reviewing them is the slow part. The agent finishes, prints a file tree, and you are left pulling the branch, installing dependencies, and starting a dev server just to see whether the thing works.

A preview URL removes that loop. The agent's code runs where it was written, on a machine built for exactly this job, and the platform hands you a link. This post explains what that preview URL actually is, what kind of machine sits behind it, and what to check before you trust one with code nobody on your team has read.

Key Takeaways

A live preview URL is a public web address mapped to a port inside an isolated sandbox, so you can open an agent-built app in a browser without checking out the code locally.
The right backing machine is a Firecracker microVM with its own guest kernel, not a container, because agent-written code is untrusted code.
Outbound access from the sandbox is open until you set at least one egress rule; once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
Pause, resume, and fork let you keep a preview alive without paying for idle compute, and branch the app's state to compare candidate fixes side by side.
CreateOS Sandbox includes live web URLs, headless Chromium with a DevTools port, two-way file sync, per-second billing, and $0 egress, with 500 free credits for new accounts.

What a Live Preview URL Actually Is

The mechanism is simple. Your sandbox is a full virtual machine with its own network stack. When your coding agent starts a dev server inside it, on port 3000 or 5173 or 8080, the sandbox platform maps that port to a stable public URL. Open the URL and you are talking to the app running inside the VM.

This is different from a screenshot. A screenshot shows you one frame. A live URL hands you the running application: click the buttons, submit the forms, watch the state update. CreateOS Sandbox exposes a live web URL for anything running inside a sandbox, plus a headless Chromium with a DevTools port on a public URL when the app needs a browser to render at all.

It is also different from running the app on your laptop. The agent's code never touches your machine. Dependencies install inside the sandbox, the server starts inside the sandbox, and your browser is the only thing that crosses the boundary.

Why the Machine Behind the Preview Matters

The preview URL is the visible part. The isolation behind it is the part that matters.

Agent-written code is code nobody reviewed. It may be fine. It may also reach for the network, delete files, or do something the prompt never asked for. Running that on your workstation, or in a shared container on a shared kernel, means trusting code you have not read.

CreateOS Sandbox gives every session a Firecracker microVM with its own guest kernel. That is a machine boundary, not a process boundary. Code inside the VM cannot see the host kernel, other sandboxes, or your filesystem. When the review is done, you destroy the machine and nothing lingers.

One constraint to know: isolation is on by default, but egress restriction is not. A sandbox with no egress rules has open outbound access. Deny-by-default starts once you set at least one rule. You set rules through the egress field at create time, the egress API endpoint, the SDK's setEgress method, or the CLI. Once set, everything not on the allowlist is denied, and the enforcement runs in the host kernel with eBPF, outside the guest, so code inside the VM cannot rewrite or route around it. Inbound is closed by default regardless.

The Review Workflow This Enables

Here is the loop in practice.

Your coding agent builds the app and runs it inside a sandbox.
The platform returns a live preview URL. You open it and use the app.
Something is wrong? The agent keeps its machine. It reads the same filesystem, sees the same logs, and fixes the bug in place. You refresh the URL.
Something is right? Pause the sandbox. Pausing writes a snapshot of full guest state, memory and disk, and stops compute billing. Resume restores that exact machine when you need it again.

Forking is where this gets interesting for review. Fork a paused sandbox and you branch its memory and working state. Now you can run two candidate fixes in parallel, open two preview URLs, and keep the winner. You are comparing running applications, not diffs.

Two-way file sync keeps your editor and the sandbox in step while you work, so the preview and your local view of the code never drift apart.

What to Check Before You Pick a Sandbox for This

Not every preview URL is backed by the same guarantees. Four things to verify:

Isolation boundary. Ask whether the preview runs in its own VM with its own kernel, or in a container sharing a kernel with other workloads. For untrusted code, the VM boundary is the one that holds.

Egress control. Can you allowlist exactly the hosts the app may reach, enforced outside the guest? If the answer is "the sandbox can reach anything," your agent-built app can too.

Cost while idle. Previews get abandoned. Per-second billing with pause stopping the meter means an idle preview costs nothing. CreateOS Sandbox bills per second, charges $0 egress, and auto-pauses on idle with a configurable timeout.

Where the code runs. If the app handles anything sensitive, you may want it on your infrastructure. CreateOS supports bring-your-own compute with the same API, bring-your-own S3-compatible storage, and self-hosting the control plane when code cannot leave your boundary.

Shapes run from a quarter CPU up to 8 CPUs with 16 GB of RAM and 10 to 60 GB of disk, so a static page and a full-stack app both fit. New accounts start with 500 free credits, which is enough to run this workflow end to end before paying anything. See the Sandbox product page and sandbox pricing for current limits, and the docs for the SDK and CLI.

Frequently Asked Questions

Do I need to expose ports manually to get a preview URL? No. The platform maps anything running inside the sandbox to a live web URL automatically. Start a dev server inside the machine, open the URL, use the app. A headless Chromium with a DevTools port is also available on a public URL when the app needs a browser.

Is the preview URL safe for code my agent wrote? The URL is just the entry point. The safety comes from the machine behind it: a Firecracker microVM with its own guest kernel, destroyed when you are done. For outbound traffic, remember the default: outbound access is open until you set at least one egress rule, after which everything else is denied and enforced in the host kernel.

What happens to the preview when I stop working? You can pause the sandbox, which snapshots full guest state and stops compute billing. Resume brings back the exact same machine, preview included. Idle sandboxes auto-pause on a configurable timeout, so an abandoned preview does not run a bill.

Can I run two versions of the app and compare them? Yes. Fork a paused sandbox to branch its memory and working state, run both versions in parallel, and open each one's preview URL. Keep the winner and destroy the rest.

Conclusion

A live preview URL turns agent output from a pile of files into something you can judge in a browser tab. The quality of that workflow depends on what sits behind the URL: a real machine boundary for untrusted code, egress rules you control, and a billing model that does not punish you for leaving a preview running.

CreateOS Sandbox was built for exactly this loop. Every session gets its own Firecracker microVM, live web URLs come standard, pause and fork make review cheap, and bring-your-own compute keeps sensitive apps inside your own boundary. Start free with 500 credits at createos.sh and give your agent's next build a URL instead of a file tree.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.