What You Can Do with Hyperbrowser Sandboxes and Memory Snapshots

Hyperbrowser sandboxes let you run code in isolated virtual machines that are separate from your main application, and memory snapshots let you save a configured environment so later runs can restore it instead of rebuilding it. Use them when an agent or workflow needs to install dependencies, execute commands, or expose local services without touching your production environment. The Node.js SDK covers the full loop: create a sandbox, run commands, and save a snapshot for reuse.

What a sandbox is for

A sandbox is an isolated VM you control through the Hyperbrowser SDK. Hyperbrowser describes the purpose directly: run commands in isolated virtual machines, separate from your application. That separation matters when agent-generated code is unpredictable — a failed install or a runaway process stays inside the sandbox.

The documented capabilities are:

• Install dependencies — set up packages the task needs before running it.
• Execute commands — run shell commands inside the VM and read the output.
• Expose local services — make a service running inside the sandbox reachable, so a browser session or agent can interact with it.

Creating a sandbox and running a command

The site's example uses the Node.js SDK. You specify an image name, execute a command, then snapshot the result:

const vm = await client.sandboxes.create({
  imageName: "node",
});

await vm.exec("echo Sandbox ready");

await vm.createMemorySnapshot({
  snapshotName: "node-base",
});

What happens at each step:

1. Input: an image name ("node" in the example) selects the base environment.
2. Action: sandboxes.create provisions the isolated VM.
3. Expected result: a sandbox object you can call exec on.
4. Action: vm.exec runs a command inside the VM and returns its output — the example expects Sandbox ready.
5. Action: createMemorySnapshot saves the environment under a name you choose.

How memory snapshots work

A memory snapshot captures the state of a sandbox environment so you can restore it in a later run. The practical effect is that expensive setup — dependency installs, configuration, service startup — happens once, and subsequent runs start from the saved state.

Two things to keep in mind when planning around snapshots:

• Name them meaningfully. The snapshot name ("node-base" above) is how you identify the environment to restore later, so pick names that describe the stack, not the run.
• Snapshot after verification. Take the snapshot once exec confirms the environment is in the state you want; a snapshot of a half-installed environment just reproduces the problem.

The site also notes that sandbox environments can be restored from memory snapshots, and separately that browser profiles can be reused with saved cookies and logins — the two are distinct: snapshots cover the compute environment, saved browser state covers sessions.

Choosing between sandboxes and browser sessions

Both are part of the same platform, but they solve different problems:

A common pattern combines them: a sandbox hosts a service or script, and a browser session connects to it or to the web. The site's own framing is "browsers, compute, and web data" as three connected pieces.

Getting started and what to check

Hyperbrowser lists a free tier: $0 to start with 5,000 credits included. The site does not publish per-sandbox pricing details on the pages referenced here, so check the pricing page before committing to heavy snapshot or concurrency use.

Before building on sandboxes, confirm:

• SDK access — the examples use the Node.js SDK; the site also lists Python SDK, CLI, and MCP integrations.
• Image availability — the example uses a node image; verify the image you need is offered.
• Debugging path — session recordings and live inspection are described for browser sessions; use them to watch agent runs when a sandbox task fails.

If your task is "run this agent's code somewhere safe and don't pay the setup cost every time," a sandbox plus a named memory snapshot is the direct fit.