smolmachines / smolvm as a sandbox for untrusted Python & JavaScript
- ID
- 15852
- Status
- summarized
- Published
- 20 Aug 2026, 7:16 AM
- Fetched
- 21 Aug 2026, 8:10 AM
- Provider
- Simon Willison
- Category
- developer-ai
- Original URL
- https://simonwillison.net/2026/Aug/19/smolmachines-untrusted-sandbox/
- Source URL
- https://simonwillison.net/atom/everything/
Summary
- Score
- 7.5
- Created
- 21 Aug 2026, 8:10 AM
- Tags
- Audience
- developersai_agent_userssaas_foundersai_ml_learners
What happened
Simon Willison tested smolvm 1.8.3 as a sandbox for running untrusted Python and JavaScript data transformations using hardware-isolated VMs rather than shared-kernel containers. Features including no-network execution, CPU/RAM limits, guest-enforced timeouts, storage quotas, read-only input mounts, writable output mounts, and --unprivileged mode all worked as intended, with cold starts at 0.6–1.5 seconds and warm executions around 50 ms. Claude Fable 5, tasked with running the tests inside Claude Code for web, hit a nested-virtualization wall (no /dev/kvm) and creatively pivoted to GitHub Actions runners which expose /dev/kvm.
Why it matters
If you are building AI agent pipelines or SaaS features that execute user-provided code, smolvm offers a hardware-isolated alternative to Docker-based sandboxes with sub-second cold starts and 50 ms warm executions — worth evaluating against your current container approach, especially if you need strong isolation guarantees that shared-kernel containers do not provide.
Discussion angle
Compare smolvm's hardware-VM isolation model against Docker/Firecracker/gVisor for running untrusted LLM-generated code — what are the tradeoffs in cold-start latency, security boundary strength, and operational complexity for a Malaysian startup building agent-based data pipelines?