Berry Wiki

SmolVM

Properties2
tagsai, sandboxing
aliasesSmolvm

7 min read

SmolVM

Identity

The Hacker News reference is ambiguous. Comment 48894051 says only “Then use SmolVM” and includes no link. On 2026-07-13, two active projects used that name:

  • Likely match: CelestoAI/SmolVM, an AI-agent sandbox using Firecracker on Linux and QEMU on macOS. Its exact capitalization, agent focus, and positioning match the discussion.

  • Other plausible match: smol-machines/smolvm, a Rust project for portable, self-contained microVMs. It also targets coding-agent use and existed before the comment.

No authoritative source ties the HN commenter to either repository. The research below covers CelestoAI/SmolVM because it is the closer contextual match, without claiming the identity is proven.

Summary

CelestoAI/SmolVM gives AI agents disposable, hardware-isolated computers for code execution, browser use, and desktop automation. It offers Python and command-line interfaces, persistent state, snapshots, file sharing, and agent-specific launch commands.

Problem

AI agents need broad access to shells, browsers, and project files, but running generated commands on the host risks data loss and secret theft. SmolVM places each workload in a separate microVM while keeping setup close to a normal Python library or command-line tool.

How It Works

  • MicroVM backends: Firecracker and KVM provide Linux isolation; QEMU is used on macOS. The repository also describes a unified interface for libkrun.

  • Guest agent: A component inside the VM runs commands, transfers files, and reports results to the host library.

  • Disposable or persistent: A sandbox can be destroyed after one job or retained across a multi-step workflow.

  • Snapshots: Disk, memory, and running-process state can be paused and restored.

  • Browser and desktop: Chromium automation, a browser viewer, VNC, and full desktop sessions support computer-use agents.

Security Boundary

  • Separate kernel: Each sandbox runs as a virtual machine rather than sharing the host kernel like a normal container.

  • Backend dependence: Protection relies on KVM, Firecracker, QEMU or libkrun, the guest kernel, and SmolVM’s host and guest components.

  • Mount exposure: Host mounts are read-only by default. --writable-mounts makes every mount on that command writable, so a guest can immediately alter those host files.

  • Network exposure: Sandboxes have full internet access by default. Domain rules must be enabled deliberately.

  • SSH trust caveat: SmolVM automatically accepts an unknown sandbox SSH host key on first connection. Its security policy says this can permit a person-in-the-middle attack on an untrusted network.

  • Trusted local model: The maintainers recommend local machines or trusted CI runners and warn against publicly exposing guest SSH ports without extra controls.

Platforms and Agents

  • Hosts: Supported Linux and macOS systems. Linux uses Firecracker/KVM; macOS uses QEMU.

  • Guests: Linux is the main workload. Windows 11 guests are supported only on Linux with KVM; Windows host mounts, network controls, and snapshots were not supported at the check date.

  • Coding agents: One-command environments are documented for Claude Code, Codex, and Pi.

  • Frameworks: Official examples cover OpenAI Agents, LangChain, PydanticAI, browser automation, computer use, and OpenClaw.

Setup

  • Installer: The project offers an installation script from celesto.ai.

  • Manual route: Install the smolvm Python package, then run smolvm setup and smolvm doctor.

  • Dependencies: Supported systems receive a matching smolvm-core wheel. Linux setup may request elevated permission to install host requirements and configure runtime permissions.

  • Basic workflow: Create a sandbox through Python or the command line, run commands or open a shell, then stop it.

Network and Credentials

  • Default egress: Full internet access is enabled unless configured otherwise.

  • Domain rules: internet_settings can allow only named domains. The README demonstrates blocking destinations outside that list.

  • Git credentials: Coding-agent launch commands advertise forwarded git credentials. This is convenient but lets the guest act with the forwarded identity’s permissions.

  • Environment values: The library can inject environment variables into a sandbox. No general secret broker or automatic content redaction is described in the overview.

  • Host files: Read-only mounts reduce accidental damage but do not stop an agent from reading or sending their contents to an allowed destination.

  • Public ports: Browser and desktop viewers use local endpoints. Guest SSH and viewer endpoints should not be exposed to untrusted networks without authentication and firewall controls.

Strengths

  • Agent-focused: Ready-made Claude, Codex, Pi, browser, desktop, and framework workflows reduce integration work.

  • Hardware isolation: Separate virtual machines provide a stronger boundary than shared-kernel containers.

  • Fast lifecycle: The project reports roughly 500 ms VM startup, with its benchmark suite available for local verification.

  • Useful controls: Domain filtering, read-only default mounts, snapshots, persistent sessions, and disposable sandboxes cover common agent needs.

  • Cross-host API: The same Python and command-line shape works across the supported Linux and macOS backends.

  • Open source: Apache-2.0 licensing and published source permit inspection and self-hosting.

Limits

  • Identity uncertainty: The HN comment may instead refer to smol-machines/smolvm.

  • Pre-1.0: The security policy identifies the project as pre-1.0 and supports only the latest release and main branch on a best-effort basis.

  • Permissive defaults: Internet access is on by default, and unknown SSH host keys are trusted on first connection.

  • Writable-mount scope: The writable flag applies to all mounts in that launch, not selected folders individually.

  • Platform differences: Firecracker, QEMU, libkrun, Linux, macOS, and Windows paths do not offer identical features or security behavior.

  • Local resource cost: Each sandbox consumes host CPU, memory, and storage; high-density claims need verification on the intended hardware.

Activity and Maturity

Checked 2026-07-14.

  • Celesto repository: Created 2026-02-15, with 377 commits, about 695 stars, 52 forks, and 12 combined open issues and pull requests.

  • Latest Celesto release: v0.0.26, published 2026-07-09. It fixed Firecracker guest network egress.

  • Latest Celesto commit: 720f4d5c4e4a432f34c47b111f1d79869e9b73ab on 2026-07-13, refreshing workflow documentation.

  • Alternative project: smol-machines/smolvm was created 2025-12-18 and remained active on 2026-07-14, with about 4,395 stars and 201 forks.

  • Assessment: Both names point to active young projects. CelestoAI/SmolVM has rapid releases and substantial scope but remains explicitly pre-1.0.

Best Fit

  • Good fit: Local or trusted-CI agent execution needing microVM isolation, Python integration, browser sessions, snapshots, or ready-made coding-agent commands.

  • Good fit: Teams willing to pin the latest release, test their backend, restrict network access, and use narrowly scoped credentials.

  • Poor fit: Untrusted networks, public multi-tenant hosting without added controls, stable 1.0 compatibility requirements, or identical features across every host and guest.

Comparison

  • Versus Clawk: Both target coding agents with hardware-isolated local VMs and network controls. SmolVM exposes broader Python, browser, desktop, snapshot, and framework APIs; Clawk centers the repository-to-agent workflow and a hostname-filtered proxy.

  • Versus SandBoxy: SmolVM supports Linux and macOS hosts plus several agents and browser workflows. SandBoxy is a narrower Apple framework example for macOS 26 on Apple silicon.

  • Versus Quickemu: SmolVM focuses on fast, automated agent sandboxes. Quickemu focuses on long-lived general desktop VMs across a much larger operating-system catalog.

  • Versus AgentVM: SmolVM uses native virtualization and separate guest kernels. AgentVM emulates Linux inside WebAssembly and explicitly warns that its WASI foundation may have security flaws.

  • Versus smol-machines/smolvm: Celesto emphasizes Python agent infrastructure, browser use, and multiple virtual-machine backends. Smol Machines emphasizes portable .smolmachine artifacts and a Rust runtime spanning local, cloud, and self-hosted execution. They are distinct projects.

Hacker News Context

The comment followed a claim that shared-kernel containers leave a larger attack surface than virtualization. The reply, “Then use SmolVM,” offered it as a virtualized alternative. A later commenter said they already used their own QEMU-based tool, virtdev. Because the SmolVM reply supplied no link, its exact project identity cannot be confirmed.

Direct Sources

Unknowns

  • Exact identity: Only the HN commenter can establish which SmolVM they meant.

  • Independent audit: No independent security audit was found for CelestoAI/SmolVM.

  • Domain-filter bypasses: Coverage for direct IP addresses, alternate DNS, encrypted DNS, QUIC, redirects, and unusual protocols needs testing.

  • Credential scope: The exact git credential-forwarding mechanism and revocation behavior were not established from the overview.

  • Backend parity: Security and feature differences among Firecracker, QEMU, and libkrun need a backend-specific review.

  • Benchmark portability: Startup and density results need reproduction on the user’s hardware and workload.

  • Viewer security: Authentication and exposure behavior for browser, VNC, and desktop endpoints need deployment-specific verification.

Sources

    • imported AI research note for Smolvm.

Graph View