Skip to main content
Your automation code stays on the host; only the browser and everything it downloads run in the microVM, so a malicious script or a leaking process cannot reach your machine. Useful for scraping untrusted sites, parallel cross-browser testing, and giving an agent a controllable browser.

Quick Example

The simplest happy path: start a BrowserBox, get a WebSocket endpoint, connect with local Playwright, and open a page.
When the async with block exits, the box stops and is cleaned up automatically (auto_remove is enabled by default).

Reference and troubleshooting

BrowserBox construction options, the two connection modes, the port model, and the full troubleshooting list (Playwright version pinning, WebKit limits, port conflicts, connection timeouts) are documented once on Browser automation — that page is the reference for both the agent-driven and the human-driven paths.

Take over the browser from your own DevTools

The Quick Example above connects a script to the box. To drive the browser by hand instead, ask for the Chrome DevTools Protocol (CDP) address and paste it into chrome://inspect — you then inspect pages and tune selectors in your own DevTools while the browser itself stays inside the sandbox.
endpoint() and playwright_endpoint() are mutually exclusive on one instance — calling the second one after the first raises RuntimeError. Pick the CDP endpoint for hands-on debugging, the Playwright endpoint for scripts.