Choosing a Sandbox With a Live Preview URL for What Your Coding Agent Just Built

Your coding agent writes an app in seconds. Showing it to someone is the harder part. The choice is between running the app on your laptop, wrapping it in a container on shared infrastructure, or giving it its own machine with a URL you can paste into a chat. This guide walks through that decision with the criteria that actually matter when the code was written by something you have not reviewed.

Introduction

A live preview URL sounds like a small feature. It is not. It is the difference between "the agent says it works" and "click this link and see for yourself." Developers reviewing agent output, product managers testing a prototype, and teammates giving feedback all need the same thing: a reachable URL that serves what the model just wrote, without you babysitting a dev server.

The decision is really about where that app runs. Three options cover most cases. Your own machine is free and fast but dies when you close the lid. A shared container is cheap but puts untrusted, agent-written code next to other workloads. A dedicated microVM sandbox gives the app its own kernel and a public URL, at the cost of per-second billing instead of a flat subscription.

If the code came from your agent, treat it the way you treat code from a stranger on the internet. That single assumption drives most of the decision.

Key Takeaways

Isolation from your other work. Agent-written code is untrusted until reviewed. A sandbox with its own guest kernel keeps a compromised app away from your files, credentials, and network.
A URL that survives the session. The preview should work while the agent keeps editing, pause when nobody is looking, and resume on the next request.
Egress you can govern. The app will call APIs. Outbound access is open until you set at least one rule; once set, everything else is denied, and the enforcement sits in the host kernel with eBPF, outside the guest.
Cost that matches usage. Previews are bursty. Per-second billing with no egress fees beats a flat plan you mostly leave idle.
Portability. If the prototype graduates into a real project, you should not have to rebuild the runtime.

Decision criteria

1. What happens if the code misbehaves? This is the first filter. On your laptop, a bad dependency reads your environment variables. In a shared container, it can see a neighbor. In a Firecracker microVM, the app gets its own guest kernel, so a full compromise stops at the VM boundary. If you cannot vouch for the code, and you cannot when an agent wrote it minutes ago, this criterion decides more than any other.

2. Who needs the link, and for how long? A URL on localhost forwarding works for you alone. A teammate in another timezone needs something that stays up while your machine sleeps. Sandboxes built for this case support pause and resume from a memory-plus-disk snapshot, so the preview comes back on the next request instead of requiring a rebuild.

3. What does the app need to reach? Most agent-built apps call external APIs: a model endpoint, a payment test key, a database. Decide whether outbound should be open while you prototype or restricted to a known host list. The allowlist is set through the egress field at sandbox create time, a live API update, the SDK's setEgress method, or the CLI. Rules take hosts, ports, wildcard subdomains, IPs and CIDRs, and they are enforced on the host, not inside the VM where the app could rewrite them.

4. What does idle time cost? A preview that runs all night on a flat-rate container costs the same as one that runs all day. Per-second billing charges only for the seconds the machine exists, and idle timeout auto-pause stops the meter when nobody is clicking. For bursty preview traffic, the difference compounds quickly.

5. Can you get the app out later? Two-way file sync and bring-your-own Dockerfile mean the prototype is not locked into the platform. If the sandbox vendor cannot hand you the app as a plain artifact, you are renting, not building.

How to choose

If the app is a throwaway demo and only you will see it, run it locally. Nothing beats zero setup for a five-minute check. Accept the risk: you reviewed the diff, or you accept that you did not.

If teammates or stakeholders need the link, you need a URL that outlives your laptop. A dedicated sandbox is the fit here. CreateOS Sandbox gives every session its own microVM with a live web URL for anything running, so the link you paste into the review thread serves the app the agent just wrote, not a stale build. Pause on idle keeps it from billing you overnight, and resume brings the exact state back.

If the agent's code calls third-party APIs with real credentials, govern the egress. Set an allowlist from the start: the app reaches the hosts you name and nothing else, and the rule survives even a full guest compromise because enforcement sits in the host kernel. This is the criterion most teams skip and later regret.

If you are running many previews at once, for example an agent platform generating candidate builds for several users, isolation per session stops one customer's code from seeing another's machine. Private networking between sandboxes lets multi-agent setups find each other by name without touching the public internet.

If the prototype becomes a product, bring your own compute applies the same API on your own machines, and bring your own bucket keeps artifacts in your S3, R2, or MinIO. The migration path matters more than the starting price.

The through-line: the less you trust the code, the more the runtime has to do for you. A laptop trusts you. A shared container trusts the neighbor. A microVM trusts no one, which is the correct default for agent output.

Frequently Asked Questions

Do I need to configure networking before the preview URL works? No. Inbound is closed by default, and the preview URL is served for you. Outbound access is open until you set at least one egress rule; once set, everything else is denied. Set rules through the API, SDK, or CLI, and they apply live without a restart.

What happens when someone opens the link after the sandbox has been idle? The sandbox auto-resumes on ingress HTTP. The first request after a pause waits for the resume, then the app serves exactly the state it had, because pause captures memory plus disk.

How fast is a fresh preview environment? Sandbox creation restores from snapshot rather than cold boot, in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA. The mechanics are in the Sandbox docs.

What does this cost compared with leaving a dev server running? Pricing is per-second with $0 egress, and new accounts start with 500 free credits. See the Sandbox pricing page for current shapes, which range from a quarter CPU up to 8 CPU / 16 GB with 10 to 60 GB of disk.

Conclusion

The decision reduces to one question: how much do you trust the code your agent just wrote? If the answer is "not enough to run it next to my real work," and it should be, then the preview URL needs to come from a runtime built for untrusted code. A Firecracker microVM with its own guest kernel, a live URL for anything running, host-enforced egress once you set rules, and per-second billing covers the preview case without asking you to choose between safety and convenience. Start with the CreateOS Sandbox product page, read the docs for the egress and pause-resume mechanics, and spin up your first preview with the free credits.

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.