Docker
The managed Docker engine, the workspace for what runs inside it, and how both stay out of the way of the Docker you already have.
This page has not been translated into Bahasa Indonesia yet, so the English text is shown.
Containers on a Mac always run inside a Linux VM. 1VMTool can be the thing that manages that VM — a Debian machine in your library running upstream Docker — or it can simply drive a Docker you already have. Both arrive through the same workspace.
The managed engine
1vm engine setup
That downloads a pinned Debian 13 ARM64 cloud image (about 204 MB), verifies its
SHA-512, provisions Docker into it and boots it on Virtualization.framework.
--no-start prepares the disk without the first boot.
The engine is an ordinary machine in the library. It appears in the sidebar with its memory, and that memory counts against the same library budget every other machine draws from — so the app can tell you the Mac is tight before you start something else, not after. It can run alongside a regular VM, on either tier.
| Command | What it does |
|---|---|
engine setup | Download and provision the managed Debian engine |
engine start|stop|restart | Manage the engine VM (stop --force is available) |
engine status [--json] | State, socket path and owned Docker context |
engine logs | Setup and daemon diagnostics |
engine service-stop | Stop socket activation without deleting data |
engine delete --force | Delete the engine and all its container data |
It does not touch your Docker context
The engine registers a Docker context named 1vm pointing at a private
docker.sock, and it never changes your selected global context. Docker
Desktop, Colima, a remote host — whatever docker context ls says today keeps
saying it after setup.
To reach the private socket without changing anything:
1vm docker ps
1vm docker compose up -d
Anything after docker is passed to the Docker CLI. If the engine is stopped,
the connection starts it: socket activation deliberately outlives the app, so a
client connecting after you have quit 1VMTool still finds an engine.
The workspace
The sidebar's Docker section has five pages — Docker Engine, Containers, Images, Volumes and Networks. The Connection picker at the top right chooses which Docker engine they describe; every context on the Mac is selectable, not just the managed one. Resources belong to the selected connection, and switching connections clears any selection you had made.
Containers are grouped by Compose project, with everything else under Standalone. Search matches name, image, project and status, and Running only hides the stopped ones. Per container you get logs, live stats and a Terminal action. The list refreshes every five seconds.
The action buttons are per page: Compose Up… and Run Container… on Containers; Build…, Pull… and Load… on Images; Create Volume… and Create Network… on the last two.
The usage overview
Containers, Images and Volumes each open with four figures and a breakdown card.
| Page | Tiles | Breakdown |
|---|---|---|
| Containers | Running of total, Stopped, Compose projects, writable layer with its reclaimable share | Workload — a share bar, the published-port count, and a running-over-total meter per Compose project |
| Images | Images (untagged called out), Disk, In use, Reclaimable | Largest images, ranked, with build cache reported separately |
| Volumes | Volumes, In use, Disk, Unused | Attachment, the driver mix, and the first five volumes nothing has mounted, by name |
Sizes come from docker system df when the engine reports it and fall back to
what the listings say when it does not. A tile that genuinely cannot know says
so — Size is unavailable for this engine — rather than showing a zero you
would have believed.
Selecting and deleting
Every row on Containers, Images, Volumes and Networks has a selection toggle. Select All takes everything the current filter shows, so search or filter first and you are acting on exactly the subset in front of you. The toolbar reports N selected and Delete Selected… confirms before anything happens.
The confirmation states the consequence. For volumes: all data in these volumes will be permanently removed, and Docker will refuse any deletion while a container uses the volume. For everything else: this removes the selected resources from the current connection, and running or referenced resources will be kept if Docker refuses the deletion. Docker's own safety rules are never forced past.
Deleting the engine itself is the one irreversible action here, and it is explicit about scope: it permanently removes every container, image and volume in the 1VM engine, and keeps other Docker contexts.
What it needs
Docker management uses the host Docker CLI, and Compose and Buildx actions need their corresponding CLI plugins. Nothing else — the engine's guest side is provisioned during setup.
If something fails to list
A single failed listing — an unreadable image-store blob is the usual cause — no
longer marks the whole engine disconnected. The other pages stay available and
the message names what to repair. If the engine itself is unreachable,
1vm engine logs prints the setup log and the last hundred lines of the Docker
journal.
For ports published by ordinary Linux machines rather than containers, see Networking. For the commands in full, see The 1vm command line.