BoxerDock gives each AI agent and service its own featherweight virtual machine (VM) on your Mac. A napping box costs 0.00 MB of host RAM, wakes in 0.70 seconds, and one command rolls back what an agent breaks inside it.
Built on Apple's open-source container runtime (Apache 2.0). For Apple silicon Macs on macOS 26.
The real commands, with measured timings.
You know the feeling: OrbStack ate 3 GB and never gave it back. Docker Desktop keeps a virtual machine warm all day for a Postgres you queried once at breakfast. Container runtimes on the Mac share one big VM, and that VM holds its memory until you restart it.
AI agents multiply the bill. Every Claude Code experiment wants its own Postgres, its own Redis, its own place to run untrusted code. Give an agent your real filesystem and you are one confident wrong command away from a bad afternoon. Send the work to a cloud sandbox and your code leaves your machine while a per-second meter runs.
host RAM for one nginx:alpine on OrbStack, freshly started VM. A ballooned copy of the same VM held 3,211 MB. Measured 2026-08-13.
of disk idled in the same OrbStack data store, presented as a 926 GB sparse file.
host RAM for the identical nginx on BoxerDock, running. While napping: 0.00 MB. Same day, same Mac.
Every performance figure on this page comes from a benched lifecycle you can reproduce with one built-in command, boxerdock bench. These are the clean-machine figures from 2026-08-14 on a 32 GB Apple silicon MacBook Pro running macOS 26, load average 11; vendor prices and their dates are linked where they appear.
| Metric | Measured |
|---|---|
| Cold boot to running box | 1.87 s |
| Exec round-trip, warm | 0.07 s |
| Idle memory (RSS), running | 39.75 MB |
| Memory (RSS) while napping | 0.00 MB |
| Wake | 0.70 s |
| Exec after wake | 0.05 s |
| nginx:alpine | BoxerDock | OrbStack |
|---|---|---|
| RAM while running | 38 MB | 1,459 MB |
| RAM while idle | 0 MB (napped in 0.38 s) | VM resident until restart |
| Start to running service | 0.80 s (image cached) | ~45 s app and VM start |
The zero is structural, not a tuning trick. Each box is its own lightweight VM; when a box naps, its VM exits. There is no shared always-on VM and no memory high-water mark waiting for a restart. The number is 0.00 MB whatever your machine is doing that day.
Isolation is measured the same way. A box on its own network cannot reach a box on another network, and can reach its same-network neighbor, verified with a positive control on macOS 26. Snapshot and restore were verified in both directions: a marker file survived the rollback and injected damage did not.
And it is carrying real work today: two full service stacks, 10 services in all (Postgres, Redis, LiteLLM, Open WebUI, n8n, Uptime Kuma, ntfy, plus a three-service media stack), migrated off OrbStack and verified responding, at roughly 260 MB of combined host memory (resident set size, RSS). Head-to-head and conditions are documented on the capabilities page.
A box is a container with a bed. It boots fast, works like any standard container, and sleeps for free.
boxerdock up agent boots a box in its own lightweight VM with its own Linux kernel, in under two seconds.
Exec commands, publish ports, mount folders, build Dockerfiles, run x86 images through Rosetta. Standard images, standard workflow.
The box's VM exits. Disk state persists, host RAM drops to 0.00 MB. Autonap does this for idle boxes on its own.
You are 0.70 seconds from a running box, files and services where you left them.
snapshot before you let an agent loose; restore rolls the whole box back to that moment.
Underneath sits Apple's open-source container runtime (Apache 2.0), the same substrate Apple ships for macOS 26, vendored user-local: no kernel extensions, no sudo, nothing global. BoxerDock adds the model that makes it a home: naps, autonap policies, snapshots, a bench that keeps the numbers checkable, and a LaunchAgent so your boxes survive a reboot.
The whole idea fits in one sentence: containers gave you cheap processes, and boxes give you cheap machines. Because each box carries its own kernel, "off" really means off, which is where the 0.00 MB comes from; because it boots in under two seconds, off stops being a state you avoid. Autonap turns that into a habit your Mac performs for you: services you have not touched in 10 minutes stop costing anything on their own, and the first request that needs one gets it back before you notice the gap.
Give Claude Code or Codex a box instead of your Mac. Snapshot first, let it run anything, keep what worked, restore what did not.
$ boxerdock up sandbox $ boxerdock snapshot sandbox snapshot saved (9 MB) $ # agent works inside the box... $ boxerdock restore sandbox box rolled back. damage gone.
Ten real services run two production home stacks today: databases on runtime volumes, media servers on bind mounts, reachable over Tailscale, ~260 MB total while active.
$ boxerdock ls BOX STATE RSS(MB) IP ah-db running 62 192.168.64.4 ah-redis running 11 192.168.64.3 komga napping 0 ntfy napping 0
A Postgres per project, napped when you switch branches. Autonap watches for idle boxes and puts them to bed; waking one takes 0.70 seconds.
$ boxerdock autonap --idle 10m watching 4 boxes box 'pg-main' napping in 0.4s (host RSS 62 MB -> 0 MB) $ boxerdock wake pg-main awake in 0.7s
Everything below runs today on the reference machine; the roadmap section carries what ships next, each item tracked in the product backlog.
A napping box costs 0.00 MB of host RAM. Structural, measured, load-independent.
0.70 s from napping to running, files and processes intact.
One command each. Verified both directions: kept work survives, injected damage does not.
Idle boxes get put to bed automatically; you set the idle window.
Real VM isolation per box, with network separation verified by positive control.
Open Container Initiative (OCI) images, Dockerfile builds, volumes, bind mounts, published ports, logs, cp, export.
amd64 images run on Apple silicon with --arch amd64.
A LaunchAgent keeps the runtime's API server alive across restarts, verified by killing it.
boxerdock bench measures the whole lifecycle on your machine, so the claims stay checkable.
You run coding agents daily and want them fenced: their own filesystem, their own network, a snapshot before every risky run, and a one-command undo. That is the box lifecycle, verbatim.
The pattern that works: one box per agent task, snapshot before the run, let the agent install and execute whatever it decides it needs, then keep the box if the work landed or restore it if the run went sideways. The mistakes stay in the box.
Your services deserve better than a 1.5 GB always-on VM. Two real stacks (10 services) already live on BoxerDock at ~260 MB active and 0 MB napping, reachable over Tailscale.
Databases sit on runtime volumes, media libraries ride bind mounts, and the whole stack comes up from one script. To the reader on the couch, the library server was simply always on: it woke before the first page turned.
Postgres, Redis, a queue, a mock API: park them all. Autonap ends the ritual of hunting down what is eating your RAM before a build.
Branch-switching stops costing memory: the services for the project you left keep their state on disk at 0 MB, and the ones you return to answer in under a second. Your machine spends its RAM on the work in front of you.
Prices and capabilities below were read from each vendor's own pages on 2026-08-16; sources are linked. Measured figures are from the head-to-head on this page.
| BoxerDock | OrbStack | Docker Desktop | E2B | Daytona | |
|---|---|---|---|---|---|
| Host RAM, idle-but-ready service | 0.00 MB (napping) | shared VM stays resident (measured 1,459 MB, one nginx) | shared VM stays resident | runs in their cloud | runs in their cloud |
| Isolation model | one lightweight VM per box | one shared VM, all containers | one shared VM, all containers | microVM per sandbox, cloud | sandbox per workspace, cloud |
| Where your code runs | your Mac | your Mac | your Mac | their infrastructure | their infrastructure or BYO cloud |
| One-command snapshot and undo | built in | not listed | not listed | sandbox persistence per session | not listed |
| Substrate license | Apache 2.0 (Apple container) | proprietary | proprietary app | hosted service | hosted service |
"Not listed" means the capability does not appear on the vendor's public documentation or pricing pages as of 2026-08-16. Vendor pricing, read from their own pages the same day: OrbStack $8/user/mo commercial, Docker Pro from $9/mo, E2B Pro $150/mo plus usage, Daytona usage-based. BoxerDock pricing is in the pricing section.
A note on reading this table: cloud sandboxes and local runtimes are answering different questions. E2B and Daytona sell elastic compute for fleets of agents at datacenter scale, and they are good at it. BoxerDock answers the question that starts and ends on your desk: the agents and services you personally run, on the Mac you already own, where your code stays on your machine and there is no per-second meter. If your work lives on your machine, the comparison above is the one that matters.
BoxerDock is built toward one picture: every agent and service on your Mac lives in a box that costs nothing while it sleeps, answers by name, and rolls back in one command. Here is what ships next, in build order, each item tracked in the product backlog.
A local Domain Name System (DNS) domain so api reaches db.boxer, no IP pinning.
Live box list, per-box memory, nap and wake buttons, log tails, in your browser on localhost.
Box count and total RAM in the menu bar; nap-all before a big build.
Snapshots restore correctly today; next is rollback fast enough to be a reflex.
Homebrew and a signed download, so a box is one command from any Mac.
"No network", "snapshot before every run", "nap after 10 idle minutes" as named profiles you attach to a box.
BoxerDock's first users are its own builders. Ten production services came over from OrbStack in one weekend, and the lessons from that migration are baked into the product and written down here, so your first stack lands on a paved road.
Postgres and other ownership-sensitive stores get a container volume, seeded once from your old data directory. Plain file stores (media libraries, note apps, message queues with file backends) ride ordinary bind mounts and carry straight over.
A box defaults to 1 GB of RAM, which suits most services and keeps the fleet light. Memory-hungry Python images get an explicit --memory 4g, and the box uses only what the workload actually touches.
Vendor registries rate-limit repeated pulls. The launchers retry, and pulling busy images from their Docker Hub mirrors made the whole migration reproducible on the first clean run.
Boxes reach host services at the Mac's local network address, and services in boxes are reachable from your other machines the way you would expect: the media stack serves a reader on another device over Tailscale today.
The full migration record, with the measured numbers behind the performance claims on this page, lives on the capabilities page.
Your code, your prompts, and your data stay on your Mac. Boxes are isolated from each other with real VM boundaries and per-box networks, and the isolation claim is tested with a positive control, not assumed.
The BoxerDock tool itself phones nothing home. The only network traffic is what you ask for: image pulls from registries you name, and the ports you choose to publish. This website uses privacy-respecting analytics: inputs and text are masked, Do Not Track is honored, and nothing is captured from the product itself.
The trust story is inspectable rather than promised. The substrate is Apple's open-source container runtime under the Apache 2.0 license, vendored unmodified where you can read it, running user-local with no sudo, no kernel extensions, and nothing installed globally. The claims on this page carry their dates and conditions, and the built-in bench exists so the next machine to check them can be yours.
The free tier is permanent: one box, the full lifecycle, at no cost, on your own Mac.
for personal use
or $120 per year
Nothing. Nap exits the box's VM, which is what frees the RAM; the box's disk state persists exactly as it was. Wake it and your files, installed packages, and services are where you left them. Measured wake is 0.70 seconds.
Only what you explicitly mount into it. A box sees its own filesystem plus the folders you hand it with --volume. An agent inside a box with no mounts can only affect that box, and a snapshot taken before the run means even that is reversible.
boxerdock restore rolls the entire box back to your last snapshot. This is verified with a real test: a marker file written before the snapshot survives the rollback, and damage injected after it is gone.
Yes. Boxes run standard Open Container Initiative (OCI) images, build from Dockerfiles, use volumes and bind mounts, publish ports, and run amd64 images through Rosetta. Two production-grade stacks (Postgres, Redis, LiteLLM, Open WebUI, n8n, Uptime Kuma, ntfy, and a three-service media stack) were migrated straight from OrbStack with the same images.
The opposite, and that is the surprise. Apple's container runtime boots a minimal Linux VM per box in under two seconds, and a running alpine box idles at about 40 MB of host memory. Because each box is its own VM, exiting it returns everything, which is what makes 0.00 MB napping possible at all.
Apple silicon Macs on macOS 26, which is where Apple's container runtime lives. The runtime is vendored user-local: no sudo, no kernel extensions, nothing installed globally.
The substrate is: Apple's container runtime is Apache 2.0, and BoxerDock vendors it unmodified where you can read it. Vendoring means the runtime ships inside BoxerDock itself: one folder in your home directory, no system install, no kernel extensions, and the exact code your boxes run is the code Apple published. When Apple improves the runtime, BoxerDock takes the upgrade and your boxes keep their model: nap, wake, snapshot, restore.
A box is a container with its own lightweight virtual machine and its own Linux kernel. You interact with it exactly like a container: give it an image, exec commands, publish ports, mount folders. The VM underneath is what buys the two things containers on a shared VM cannot give you: a hard isolation boundary per box, and a nap that returns every byte of RAM because the VM itself exits.
One big VM gives you one lifecycle: it is either holding memory for everything or off for everything, and one process misbehaving inside it can touch everything else. Boxes make the lifecycle per service. Your database naps at 0 MB while your agent sandbox runs; rolling back the sandbox does not touch the database; and each box gets its own network, so an isolated agent cannot even ping its neighbors.
Yes. Both reference stacks run as multi-box launches today: named boxes on shared networks, databases on runtime volumes, services finding each other at boot. The launchers are plain scripts; name-based lookup (DNS) on the roadmap makes stacks read the way you would write them by hand, db.boxer instead of an IP.
The command-line tool runs today on the reference machine, which is where every performance number on this page was measured. Leave an email on the notify list and you get exactly one message: the download link.
BoxerDock is the difference between renting your Mac to your containers and owning it back: boxes that cost 0.00 MB asleep, wake in 0.70 seconds, and undo what agents break inside them. Leave an email and you get exactly one message: the download link.
If your AI assistant is evaluating tools for you, point it at boxerdock.com/capabilities: every capability with its mechanism and a way to verify it.
A napping box costs 0.00 MB and wakes in 0.70 seconds.
See what that changes