start on the machine you're holding.

01

the problem local solves

an agent that can run code can run any code. it can pip-install a package that turns out to be hostile, follow an instruction hidden in a web page, or fire off a command that deletes the wrong directory. on your laptop, that is your laptop.

microsandbox gives that code its own computer instead. a real microvm with its own kernel, booted in milliseconds, thrown away when the task ends. when the code goes wrong, it wrecks a disposable machine, not your workstation and not your private network.

02

your code, actually running

here is the whole loop: create a sandbox from an image, run code inside it, read the output, remove it. the create call is the same in every language.

that sandbox is a full linux machine with its own kernel. the code inside cannot see your host kernel, your files, or any other sandbox.

import asyncio
from microsandbox import Sandbox

async def main() -> None:
    async with await Sandbox.create(
        "python-readme", image="alpine", replace=True
    ) as sandbox:
        output = await sandbox.shell("echo 'Hello from microsandbox!'")
        print(output.stdout_text.strip())

asyncio.run(main())

03

what one command actually does

when you create a sandbox, the runtime pulls the oci image you named, boots a microvm with your machine's native hypervisor, and starts your workload as a child process of your own application. there is no privileged daemon running in the background, and no root service to compromise.

when you remove it, the kernel, memory, and disk go with it. nothing survives unless you snapshot the disk on purpose.

04

what you can build on it

• a code interpreter for your chatbot: run each model-written snippet in a fresh machine and return the output.
• one disposable computer per coding-agent task: let it edit, build, and test, then delete the machine.
• an eval harness: boot identical microvms so the only variable is the agent you are measuring.

05

the limits are real limits

set vcpus, memory, and disk per sandbox. they are enforced by the hypervisor, not requested politely from a shared kernel.

by default, sandboxes can reach the public internet. private, host-local, link-local, and metadata destinations are blocked. egress can be reduced to an allowlist or disabled entirely. in the cloud, the non-public block cannot be lifted, even by you.

so a task can be given exactly the network it needs, or none at all.

06

where local stops, and what is next

local gives you the boundary and the runtime. it does not give you managed capacity, organization identity, or per-sandbox billing. when you need to run this as a fleet or as a team, the same sandbox runs in our cloud unchanged, and the same runtime runs inside your own perimeter.