Managed Docker engine
A Debian VM running upstream Docker, provisioned by one command and removed by another. Its memory counts against the same library budget as your machines, and it never changes the Docker context you already use.
Why it matters
Containers on a Mac always run inside a Linux VM — the only question is who manages it. When that VM belongs to a separate app, it reserves memory without telling the tool running your other machines, and the first sign of the conflict is a build that got slower for no reason you can see. Here the engine is a machine in the same library, drawing from the same budget, visible in the same sidebar.
What changes
Without it
- A second virtualization stack installs itself alongside the one already running your VMs.
- Two apps reserve host memory independently, and neither mentions the other.
- Uninstalling means hunting leftovers, and your Docker context selection is whatever the installer decided.
With 1VMTool
- `1vm engine setup` downloads a pinned Debian 13 ARM64 image, verifies its SHA-512 and provisions Docker into it.
- The engine appears in the library and its RAM counts against the same memory budget as every other machine.
- `1vm engine delete --force` removes the engine and its data, and leaves every other Docker context untouched.
How it works
One command to exist
`1vm engine setup` fetches the pinned Debian cloud image (about 204 MB), checks its digest, installs Docker and boots it on Apple's Virtualization.framework. `--no-start` prepares the disk without the first boot.
It gets its own context, not yours
The engine registers a Docker context named `1vm` against a private `docker.sock`. Your selected global context is never changed, so Docker Desktop, Colima or a remote host keep working exactly as before.
Connecting starts it
`1vm docker ps` talks to the private socket directly, and socket activation starts a stopped engine when a client connects — deliberately even after the app has quit.
Ordinary machine lifecycle
`engine start`, `stop` (`--force` available), `restart`, `status --json`, `logs` for setup and daemon diagnostics, and `service-stop` to end socket activation without deleting anything.
What it covers
- Pinned, digest-verified Debian 13 ARM64 image — no third-party appliance
- Runs on Apple's Virtualization.framework alongside your other machines
- Registers a `1vm` Docker context and leaves your global selection alone
- Socket activation starts a stopped engine on first connection
- `1vm docker <args…>` runs the Docker CLI through the private socket
- `1vm engine status --json` reports state, socket path and owned context
- Runs concurrently with a regular VM, including on the free tier
- Deleting the engine removes its containers, images and volumes and nothing else
What you get out of it
- One memory budget covering both your VMs and your containers
- Containers on a Mac without a second virtualization stack to maintain
- A clean removal path: one command, no leftovers, other contexts intact
Try it on your own Mac
Every screen states its limits before you commit to anything.