A Sandbox With a Live Preview URL for the App Your Coding Agent Just Built

CreateOS Sandbox gives every session a live web URL for anything running inside it. The app your coding agent just wrote gets its own Firecracker microVM, a link you can open and share, and auto-resume when a request wakes it from an idle pause. New accounts start with 500 free credits.

Introduction

Your agent says the build is done. Now comes the awkward part: finding somewhere to look at it. Localhost dies when the agent's session ends. Deploying unreviewed, agent-written code to real infrastructure so a colleague can click one link is a bad trade. A zip file in chat is not a preview.

The job you are describing is a sandbox job. You want a machine that appears in seconds, runs code nobody has reviewed, hands you a URL for the app, and pauses without ceremony when nobody is looking. CreateOS Sandbox is built for exactly that: the runtime for the code your agents write, with a live web URL for anything running inside.

Key Takeaways

Every sandbox exposes a live web URL for anything running inside, so the app your agent wrote is openable and shareable without a deploy step.
Each preview runs in its own Firecracker microVM with its own guest kernel, not a shared container, so untrusted code stops at a machine boundary.
A configurable idle timeout auto-pauses the sandbox and stops the meter. An HTTP request to the preview URL auto-resumes it.
Outbound access stays open until you set an egress rule. Once set, everything else is denied, enforced in the host kernel with eBPF.
Per-second billing, $0 egress, and 500 free credits make the first preview a self-serve decision.

Why a Sandbox Fits the Live Preview Job

Look at what the alternatives cost you. Running the app on your laptop ties the preview to a machine that sleeps, travels, and already holds your credentials. Deploying to staging buys a pipeline run and a cleanup task for code you have not read. Hand-building a VM per demo takes minutes you never get back, and the ones you forget to kill become a bill.

The preview job has four requirements. A machine that appears fast. A boundary around code you did not write. A URL that reaches the app. A way to stop paying when nobody is looking.

CreateOS Sandbox meets all four. New sandboxes restore from snapshot in tens of milliseconds, about 30 ms on an idle host. That figure is an idle-host measurement, not an SLA. A configurable idle timeout auto-pauses the sandbox when the session goes quiet, and pausing stops compute billing. When someone opens the preview link, the inbound HTTP request auto-resumes it.

One tradeoff to plan around: the first request after a pause waits for the resume. Same-host resume lands in under 0.7 seconds. A cross-host cold start takes 11 to 13 seconds. If the first click has to be instant, keep the sandbox running or set the idle window longer.

What You Get With Each Preview Sandbox

The URL. Anything the app serves is reachable at the sandbox's live web URL. When your agent is building or testing something browser-facing, the sandbox also runs headless Chromium with a DevTools port on a public URL.

The machine. Every sandbox is a Firecracker microVM with its own guest kernel. Not a container, not a shared namespace. Code nobody has reviewed runs at a machine boundary, which is where it belongs.

The workflow. An interactive shell with SSH forwarding and two-way file sync keeps you and the agent working inside while the preview runs. Bring your own Dockerfile when the app needs an environment the templates do not cover.

The egress rule. Outbound access is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest, where code inside cannot rewrite it. Set rules with the egress field at create time, PUT /v1/sandboxes/{id}/egress, the SDK's setEgress, or createos sandbox firewall set. An app that needs one package registry and one API is a two-line allowlist.

The branch. When the app works and the agent wants to try something risky, pause the sandbox and fork it. The fork branches memory and working state, so the known-good preview stays snapshotted while the experiment runs elsewhere.

What Is Proven Today

This is a young product, and the proof is the kind you can check.

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026, so the platform builds the company's software daily.
99%+ uptime on the underlying infrastructure, operated by the infrastructure company behind CreateOS, operating production infrastructure since December 2023.
The company's own GitHub Actions runner and coding-agent plugin run on this infrastructure today.

Unit rates are published, not quoted on request. Per-second billing, $0 egress, and pause-stops-the-meter sit on the Sandbox pricing page next to the shape limits: a quarter CPU up to 8 CPUs with 16 GB of RAM, and 10 to 60 GB of disk.

What to Check Before You Commit

The egress default cuts both ways. Outbound is open until you set a rule. If the app your agent built touches anything sensitive, set the allowlist at create time, not after the first incident. Inbound network access to the machine itself is closed by default regardless.

The first click after a pause pays. Auto-resume is fast on the same host and slower across hosts. Size the idle window to how often people actually open the link.

No GPUs. If the app needs GPU inference, this is not the tool. Shapes top out at 8 CPUs and 16 GB.

Certifications are on the roadmap, not shipped, for the Sandbox surface. If a certification is your hard gate, ask about the design-partner path instead of waiting for a checkbox.

Know when you do not need it. If your team only ever runs code your own engineers wrote and reviewed, a shared dev container may be enough. CreateOS Sandbox earns its place when the code is untrusted, agent-written, or customer-written.

Frequently Asked Questions

How do I get the preview URL for my agent's app?

Create a sandbox with the SDK, the CLI (createos sandbox), or MCP, start the app inside it, and the sandbox exposes a live web URL for anything running. The docs cover the quickstart and the full API. New accounts start with 500 free credits.

What happens when someone opens the link after the sandbox paused?

Auto-resume triggers on ingress HTTP. The first request pays the resume: under 0.7 seconds on the same host, 11 to 13 seconds for a cross-host cold start. Those are idle-host figures, not an SLA. Every request after that is normal.

Is the preview link safe to share?

The isolation protects your infrastructure from the code. It does not put a password on the link. Treat a preview URL as reachable by anyone who holds it, and put your own authentication in front of anything you would not show the world. Direct network access into the sandbox is closed by default, and once you set egress rules the app cannot call hosts you did not approve.

What does a preview sandbox cost?

Per-second billing while it runs, $0 egress, and no compute charge while it is paused. Shapes run from a quarter CPU up to 8 CPUs with 16 GB of RAM and 10 to 60 GB of disk. The unit rates are published on the Sandbox pricing page, and new accounts start with 500 free credits.

Conclusion

The preview link is not a nice-to-have. It is how you check the work before you trust it. You do not need a deploy pipeline to look at what your agent built, and you should not run unreviewed code on the machine that holds your keys.

Give the app its own machine and take the URL. Start free with 500 credits on the CreateOS Sandbox product page, and read the docs before your security team asks you to.

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.