Limitations

Last updated: 2026-07-30

Some of these look like missing features. They are deliberate: each one is a container-engine behavior that does not map to a microVM boundary, so microagent refuses it rather than approximating it. See Coming from Docker: what’s intentionally different for the fuller version of several of these.

No host directory bind mounts

There is no -v /host/dir:/guest/dir. Everything the guest reads or writes is a block device - the rootfs or an attached ext4 disk - so the guest never shares a live host filesystem. Package a directory as a tar bundle for ingress, attach an ext4 disk, or use microagent cp against a stopped workspace for file transfer. See Storage and Coming from Docker: no bind mounts.

No `--privileged`

The guest already has its own kernel and full root inside the microVM, so there’s no privileged mode to escalate to - host access stays on the host. See Coming from Docker: no –privileged.

No compose projects, pods, or container-engine API

microagent isn’t a container engine. Compose projects, pods, privileged mode, namespace flags, devices, and host bind mounts fail with targeted guidance instead of being silently translated into microVM behavior. Run one image at a time with run/create; script coordination across multiple workspaces in your own tooling. See microagent run.

Intel Macs aren’t supported

macOS support requires Apple silicon and Apple Virtualization.framework - there’s no Intel Mac backend. See Host requirements: macOS.

Named volumes are single-attach, not concurrently shared

A named volume is a managed ext4 disk with a lifecycle independent of any one workspace. At most one running workspace holds it at a time - two VMs never mount the same volume read-write. This is the microVM analog of a container volume, not the Docker model of a daemon-managed, driver-based, concurrently shared volume. Hand data between workspaces by writing to the volume in one and attaching it to the next. See Storage: named volumes.

No image build command

microagent doesn’t build images. Build with the tooling you already use (Docker, Buildah, your CI) and point microagent run/rootfs build at the result - it consumes standard OCI images. To capture changes a workspace made to its rootfs, microagent commit snapshots a stopped workspace back into an OCI image. See Coming from Docker: no build command.