microsandbox

Overview

Microsandbox is a local-first runtime for isolating untrusted workloads in microVMs, from AI agents and user code to CI jobs and automation. It suits developers who need strong workload boundaries and want to run locally or on infrastructure they control. Its appeal is kernel-level isolation paired with flexible deployment; its limits are the small free cloud quota and credential-substitution constraints.

Key features

Each sandbox has its own Linux kernel, filesystem and network boundary, rather than sharing the host kernel as a container does. That makes Microsandbox a relevant choice when executing code or plugins that should not share a host kernel with other workloads.

The local runtime starts without a daemon, root service or account, keeping local use lightweight in operational requirements. SDKs for TypeScript, Rust, Python, Go and Ruby, alongside a CLI and MCP workflows, give teams several ways to integrate it. It accepts OCI images from Docker Hub, GHCR, ECR, GCR and other registries.

Network access is open to the public internet by default, while private, host-local, link-local and metadata destinations are blocked. Egress can instead be allowlisted or disabled. Bound secrets are placeholders inside the sandbox and are substituted host-side for supported intercepted requests to approved destinations. That approach has a meaningful caveat: substitution requires intercepted TLS by default, and body substitution is opt-in with format and size limits. Teams relying on credentials in varied request bodies should account for that before adopting it.

Local full snapshots can preserve disk, memory and running processes. Managed cloud snapshots are narrower: disk snapshots apply to stopped persistent sandboxes, with disk restore supported. The runtime is open source under Apache 2.0. Microsandbox Cloud is in private beta and requires an access request, so it is not an immediately available managed-cloud option for every team.

Pricing

Microsandbox is freemium, with paid plans from $49/mo. The Free plan costs nothing, billed $0 per month, and includes 5 vCPU-hours, 20 memory GiB-hours, 20 disk GiB-hours, up to three sandboxes, 1 GiB durable storage and no overage rates. Each sandbox is capped at 1 vCPU, 512 MiB memory and 8 GiB writable disk. It is suitable for small trials, but those per-sandbox caps and usage allowances constrain sustained or larger workloads.

Builder costs $49 a month, billed $49 per month. It includes 500 vCPU-hours, 2,000 memory GiB-hours, 2,000 disk GiB-hours, 50 GiB durable storage, 1,000 ephemeral-running and 50 persistent-running. This is the step up for an individual builder or small workload needing substantially more capacity than Free.

Teams costs $299 a month, billed $299 per month, and raises those quotas to 2,000 vCPU-hours, 8,000 memory GiB-hours, 8,000 disk GiB-hours, 250 GiB durable storage, 25,000 ephemeral-running and 500 persistent-running. It fits teams with heavier usage and more persistent workloads.

Enterprise has custom pricing under a custom agreement. It includes 4,000 vCPU-hours, 16,000 memory GiB-hours, 16,000 disk GiB-hours and 500 GiB durable storage; ephemeral and persistent running limits are set together, with committed or BYOC deployment models. The published quotas make the tier's scale clearer than its price, which must be negotiated.

Platforms

Microsandbox supports API access and runs on Linux, macOS and Windows, with self-hosted deployment. The runtime can run on a user's servers or clusters, and the cloud platform can also be deployed within a user's infrastructure. That makes it a fit for teams who want control over where workloads run; Cloud's private beta access requirement is a constraint for those seeking a managed service now.

Who it's for

Choose Microsandbox for untrusted code, AI agents, plugins, CI jobs, scrapers or automation when microVM isolation and local or self-managed deployment matter. It is less compelling for a small project that needs only a few tightly capped sandboxes, or for a deployment that depends on broad secret substitution or immediate access to managed cloud.

Pros and cons

• Pros: Each sandbox has its own Linux kernel and network boundary, a stronger isolation model than sharing the host kernel.
• Pros: Local startup needs no daemon, root service or account, while self-hosting supports deployment on a team's own infrastructure.
• Pros: Broad language SDK support, CLI and MCP workflows make it usable across several integration styles.
• Cons: Free sandboxes are capped at 1 vCPU, 512 MiB memory and 8 GiB writable disk, limiting heavier evaluation workloads.
• Cons: Secret substitution depends on intercepted TLS by default, and request-body substitution has opt-in and size/format constraints.
• Cons: Managed cloud is in private beta, and its snapshot support is limited to disk snapshots of stopped persistent sandboxes.

Alternatives

For a wider category comparison, browse Sandbox Software.

Consider E2B if you want an Apache-2.0 runtime that is also self-hostable; it has a free plan and API, Linux and self-hosted platforms. Choose Daytona if its broader platform coverage, including web and Windows alongside Linux and macOS, better matches your environment. ANY.RUN is another freemium option with a free Community plan and support for Android, iOS and web as well as desktop platforms.

Sandlock may suit teams seeking a free, Apache-2.0 self-hosted option described as having no caps, telemetry or registration. For Linux desktop-focused free software, consider Firejail. Anthropic Sandbox Runtime and nono are free alternatives for Linux, macOS and Windows.

CodeSandbox is a freemium alternative with web and iOS platforms; its Build and Scale plans include member limits and monthly VM credits.

Verdict

Microsandbox is a strong fit for developers who need isolated microVMs and want local operation or control of their deployment infrastructure. Its kernel boundary, integration options and self-hosting make it a clear choice for untrusted workloads. Look elsewhere if managed cloud access is essential now, if your free workloads exceed the strict per-sandbox caps, or if your credential flows do not suit its substitution limits.