Beam vs smol machines
Beam is a serverless GPU platform whose sandboxes are gVisor containers by default, with a separate line of CPU VMs. smol machines gives every machine its own microVM kernel, branches running machines with their memory, and runs the same open-source engine on your laptop or servers.
The companies and products
Beam
Beam is a serverless cloud for GPU inference, sandboxes and background jobs, built on its open-source runtime Beta9.
Beam runs functions, REST endpoints, task queues, pods, sandboxes and VMs on CPUs and GPUs, all from a Python or TypeScript SDK. A sandbox is a container isolated with gVisor that starts in a second or two, lives until you terminate it or its time to live runs out, and can be saved as a filesystem image or a memory snapshot. Beam VMs are a separate CPU product: a microVM with its own kernel, systemd and a root disk that stays when it stops. Much of Beam is a GPU serverless platform for AI teams.
- Bring your own cloud
- Management fee per vCPU and GB of RAM, on top of your own cloud bill
smol machines
smol machines makes fast, isolated Linux microVMs that run the same way on your laptop, in their hosted cloud, or on your own servers.
The core is smolvm, an open-source microVM engine built on libkrun, where each machine has its own guest kernel. smol cloud is the paid hosted service that runs fleets of those machines behind a REST API and Node, Python and Rust SDKs. It is built for developers who want one VM model from local development to production, with live branching of running machines.
- Uptime SLA
- 99.95% on Pro, Startup and Enterprise
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “8th cheapest of 345” means 7 of the other 344 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | Beam: price rank | smol machines: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month | 69th of 367, with limits $551 a month | 73rd of 367, with limits $604 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB | 115th of 366, with limits $651 a month | 148th of 366, with limits $1,038 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Both fit short code runs: Beam sandboxes start in a second or two and end on their own timer, and smol machines has a one-minute minimum and a /code endpoint for Python and JavaScript. | 8th cheapest of 345 $117 a month | 12th cheapest of 345 $140 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month All three fit; Beam gives each user a quick container, smol machines a microVM that starts on the next command, and bochka a full VM with hosting on up to 50 ports. | 3rd cheapest of 361 $290 a month | 7th cheapest of 361 $531 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month smol machines can branch a running machine with its memory and processes, and Beam can restore a memory snapshot into new sandboxes, so both can start many rollouts from one prepared state. | 341st of 360, with limits $939 a month | 111th of 360, with limits $6,978 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month Both fit eval runs; Beam's per-second containers come out lower than smol machines here, and bochka adds the coding agents preinstalled with a prompt, steer and events API. | 13th cheapest of 364 $251 a month | 36th cheapest of 364 $670 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month CI jobs that build Android apps or boot VMs need /dev/kvm, which bochka has and neither a Beam sandbox nor a smol cloud machine exposes. | 12th cheapest of 377 $171 a month | 66th cheapest of 377 $514 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A Beam VM keeps its 50 GiB root disk with no compute charge while stopped, smol machines keeps the filesystem but bills disk while stopped, and bochka keeps the disk for free. | 13th cheapest of 368 $21 a month | 216th of 368, with limits $29 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Neither Beam nor smol machines has a hosted desktop, so you would build one yourself; bochka streams a Linux desktop at 60fps with Chromium and computer use. | 111th of 369, with limits $237 a month | 90th of 369, with limits $156 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month | 195th of 367, with limits $176 a month | 176th of 367, with limits $136 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 200th of 346, with limits $131 a month | 241st of 346, with limits $242 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 42nd of 338, with limits $923 a month | 148th of 338, with limits $4,344 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 175th of 360, with limits $155 a month | 252nd of 360, with limits $377 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month Beam has GPU sandboxes and serverless GPUs up to H100, H200 and B200; smol cloud and bochka are CPU only. | Cheapest of 98 $458 a month | Can't run it | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month | Can't run it | Can't run it | Can't run it |
Key features
| Feature | Beam | smol machines | bochka |
|---|---|---|---|
| Isolation | gVisor container by default, with an opt-in microVM mode for CPU sandboxes; Beam VMs are a separate CPU microVM product | libkrun microVM with its own guest kernel for every machine | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| GPUs | GPU sandboxes and serverless GPUs, from T4 and RTX 4090 up to H100, H200 and B200 | None on smol cloud; GPU remoting only in local or self-hosted smolvm | No, CPU only |
| Docker and systemd | Docker inside sandboxes with docker_enabled; systemd only in Beam VMs | Docker inside the VM, with its data on the machine's ext4 disk; systemd not documented | Docker, systemd and root, like a normal Ubuntu server |
| Nested virtualization | Not documented in sandboxes or Beam VMs | Not exposed in the cloud create API; a local smolvm flag only | Yes, /dev/kvm for Android emulators and VMs |
| Stop and keep your files | A sandbox ends with its time to live (10 minutes by default) unless you save an image or use a volume; a Beam VM keeps a 50 GiB root disk while stopped | Filesystem survives a stop, memory paths like /tmp are emptied, and stopped disk keeps billing | Disk is saved every minute and on stop, and a stopped sandbox keeps it for free |
| Fork and snapshots | Memory snapshot of a running sandbox with its processes, restored into new sandboxes | Branch a running machine into copy-on-write children with its memory and processes; checkpoints save RAM to a file | Fork a running sandbox with its disk |
| Wake on request | No; you start sandboxes from the SDK | A command or terminal starts a stopped machine, and idle apps wake on the next request | No; a stopped sandbox is started by API |
| Inbound access | A public HTTPS URL per exposed port with no built-in auth; no raw TCP or dedicated IP | Up to 16 published ports through a returned URL or an authenticated connect route; no dedicated IP | HTTPS URLs for up to 50 ports, token-protected by default; raw TCP; dedicated IPv4 or IPv6 |
| Outbound rules | Block all outbound traffic, or allow up to 10 CIDR ranges, changeable while running | Blocked, open, or an allowlist of hosts and CIDR ranges | Open internet, no provider-side allowlist |
| Desktop and browser | No desktop or browser product | No hosted desktop; a guide shows running your own Chromium inside a machine | Linux desktop streamed at 60fps, Chromium and computer use built in |
| Coding agents | None preinstalled; you install and run them through process exec | Registry images with the Codex CLI and the Harbor eval harness, run through the command API | Seven agents preinstalled, with a prompt, steer and events API |
| Keeping API keys out of the sandbox | Secrets are environment variables inside the sandbox | Cloud secrets are environment variables the guest can read; credential swapping only in self-hosted smolvm | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Regions | US only; no other region is listed | No region choice in the cloud API | EU only (Germany, Finland, France), with EU data residency |
| Self-hosting | Beta9 runtime is AGPL-3.0 and free to self-host; bring your own cloud for a fee | Open-source smolvm runs on macOS, Linux and Windows hosts, with the same .smolmachine artifact as the cloud | No |
Every feature Battleships tracks (43)
| Feature | Beam | smol machines | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Not published | Yes |
| Systemd | No | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | No | No | Yes |
| Computer-use API | No | No | Yes |
| SSH | Yes | No | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | No | Yes | Yes |
| Automatic snapshots | No | No | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | Yes | Yes |
| Memory fork | Yes | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | No | Yes | No |
| Wake on request | No | Yes | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | Not published | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | No | No | Yes |
| Secret proxy for any API | No | No | Yes |
| Preinstalled agents | No | Yes | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | Yes | No |
| GPU | Yes | No | No |
| Windows | No | No | No |
| Arm64 | No | Yes | No |
| Self-hosting | Yes | Yes | No |
| BYOC | Yes | Yes | No |
| Open source | Yes | Yes | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | No | Yes | Yes |
| Audit logs | Not published | Not published | No |
| SSO | No | Yes | No |
| SOC 2 | Yes | No | No |
| HIPAA | Yes | No | No |
| EU data residency | Not published | No | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement: neither Beam nor smol machines has a result on the StarSling hpc-sandbox-benchmarks CPU test, so we cannot say which is faster at CPU work. bochka did 26.69 runs per second on that test at 4 vCPU / 8 GB. Beam says its sandboxes cold-boot in 1 to 3 seconds and smol machines says smolvm boots in under 200ms, which are start times, not CPU speed.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Beam and smol machines have no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | Beam, a month | smol machines, a month | bochka, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $5 · Developer | $25 · Standard | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $22 · Developer | $93 · Standard | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $410 · Team | $1,139 · Pro | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $191 · Team | $465 · Startup | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $259 · Team | $1,389 · Startup | $2,000 · $2000/mo · with limits |
Beam: Beam sandboxes bill per second for each CPU core (one core is two vCPU) and each GiB of RAM you request, until you terminate them or their time to live ends. Developer has no fee and allows 30 CPU containers; Team costs $89 a month plus usage, with no usage credit, and there are no egress fees.
smol machines: smol cloud charges a base fee for every hour a machine runs, plus the CPU and memory the guest actually uses, with a one-minute minimum and disk billed even while stopped. Pro ($20 a month) and Startup ($150 a month) are fees on top of usage, not credit.
smol machines: Plans start at $20 a month, and the whole fee is usage credit. You pay per second while a sandbox runs, and a stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Beam's Developer plan allows 30 CPU containers at once, so 50 parallel agents or 300 user sandboxes need its Team plan. smol machines caps machines by plan, 20 on Standard, 100 on Pro and 1,000 on Startup, with stopped machines still holding a slot, so 1,000 short jobs at once needs Startup. Beam publishes no price for disk, so the scenarios count no disk cost for it. bochka's limit that bites is starts: at 1,000 short jobs at once its plans queue starts, while both Beam and smol machines fit the burst.
| Scenario | Beam | smol machines | bochka |
|---|---|---|---|
| One coding agent, workdays |
| None that bite | None that bite |
| One agent that never stops |
| None that bite | None that bite |
| 50 agents in parallel |
| None that bite | None that bite |
| Sandboxes for your users |
| None that bite | None that bite |
| 1,000 short jobs at once |
| None that bite |
|
Which one should you use?
Use Beam when
your agents or evals need GPUs, when you want quick containers that clean themselves up, or when you want to self-host its open-source runtime.
- GPUs in the same platform. For agents or evals that need a GPU, Beam offers GPU sandboxes and serverless GPUs from RTX 4090 to H100, H200 and B200.
- Quick sandboxes that clean up. For short jobs, Beam sandboxes cold-boot in 1 to 3 seconds and go away on their own when their time to live ends.
- Persistent CPU VMs alongside. Teams that also want a long-lived machine get Beam VMs, with systemd and a 50 GiB root disk kept while stopped.
Use smol machines when
you want a microVM per machine by default, live branches with memory, or one open-source VM engine from your laptop to your own servers.
- A microVM for every machine. Teams that want a kernel boundary by default get a libkrun microVM with its own guest kernel on every machine.
- Live branches with memory. For RL and test fan-out, branch a running machine with its memory and processes, and wake stopped machines on the next command.
- One engine from laptop to servers. Teams that want the same VM locally, in a hosted cloud and on their own servers can use open-source smolvm, with arm64 images too.
Where bochka fits
Beam and smol machines both suit short, code-driven runs. If your agents do long work that needs a whole machine, with emulators, a desktop and a browser, hosting, and keys they cannot leak, look at bochka.
A full VM with /dev/kvm
A Beam sandbox is a gVisor container and Beam VMs document no /dev/kvm, while smol cloud does not expose nested virtualization. An agent that needs an Android emulator or a VM cannot start one on either.
Agents and a desktop built in
Neither has a hosted desktop, and Beam preinstalls no agents while smol offers Codex images run through exec calls. On both you build the agent harness, desktop and screen stream yourself before an agent can click anything.
Keys that stay outside
On Beam and on smol cloud, secrets are environment variables the agent can read, so one prompt injection can leak them. smol's credential swapping only works if you self-host smolvm and run it yourself.
Use bochka when your agents need a whole machine for real work: Docker, emulators, a desktop and a browser, hosting with access control, coding agents you drive from outside, and keys that never enter the sandbox. Compare it one to one: bochka vs Beam and bochka vs smol machines.
Questions people ask
Is Beam cheaper than smol machines?
In all five scenarios on this page, yes. One agent that never stops costs $22 on Beam against $93 a month on smol machines, and 50 agents in parallel cost $410 against $1,139. Beam publishes no disk price, so no disk cost is counted for it.
Which is faster, Beam or smol machines?
We cannot say: neither has a result on the StarSling hpc-sandbox-benchmarks CPU test. bochka did 26.69 runs per second on it. Beam sandboxes cold-boot in 1 to 3 seconds and smolvm boots in under 200ms, but those are start times.
Is a Beam sandbox a VM like smol machines?
Not by default. Beam sandboxes are containers isolated with gVisor, with an opt-in microVM mode for CPU sandboxes and a separate Beam VM product. Every smol machine is a libkrun microVM with its own kernel, and every bochka sandbox is a full VM with /dev/kvm.
Can Beam and smol machines run Docker?
Yes. Beam runs Docker inside a sandbox with docker_enabled, and smol machines runs it inside the VM with its data on the ext4 disk. bochka runs Docker in a full VM and also has systemd and /dev/kvm for emulators.
Can I fork a running machine on Beam or smol machines?
Both can. Beam takes a memory snapshot of a running sandbox and restores it into new sandboxes, and smol machines branches a running machine into children that keep its memory and processes. bochka forks a running sandbox with its disk.
Which one has GPUs?
Beam does, from T4 and RTX 4090 up to H100, H200 and B200. smol cloud has no GPUs, though self-hosted smolvm can remote GPU work. bochka is CPU only.
Try bochka
Install the CLI, then run bochka new.
Product preview