Skip to main content
The docker machine provider reaches a running container, by name, and the machine runtime runs captured programs in it. You start and stop the container; Mirage only runs programs in it. Python SDK and Node.

Installation

These serve the workspace into the container with mount_type: ssh. Start the container with FUSE allowed, from an image that has what connecting the workspace needs:

Usage

captures defaults to @external: every program Mirage does not have itself. Name @python to run Python in the container too.

Connecting the workspace

A program in the container opens workspace files at the same paths as in Mirage, so the container must see the mounts there. mount_type picks how:

ssh

  • The image needs only sshfs. No Mirage, keys or open port in the container.
  • Each file call is a round trip to the workspace; with both, keep bulk data on the container’s own mounts.
  • The container shows one session’s view, the first that runs a line there. Give each agent its own container.
  • An sshfs still serving a path Mirage serves, another workspace’s or one of your own, is left alone and the line exits 1. Give each workspace its own container.
  • If the container restarts, Mirage mounts the paths again. A line caught mid-restart exits 126 without running.
  • The root mount and /dev are not served.

fuse

Build the machine image, which carries Mirage and fuse3. Write the same mounts at the same paths into sandbox.yaml, and start Mirage with it in the container:
  • This workspace’s rules do not reach those files, so a line is refused while the session’s permissions hide or narrow anything under them.
  • If a path the container mounted goes away, as on a restart, lines exit 126 until it is mounted again. Start Mirage from the image’s entrypoint so a restart mounts it again.
  • Keep the container’s paths in step with the host’s mounts yourself. sandbox.yaml can differ where it should, such as an endpoint (host.docker.internal) or narrower credentials.

Runtime behavior

Notes

  • container takes a name or an ID. The Docker CLI is the transport, so Docker Desktop, Colima and a compatible Podman alias all work.
  • Sizing, GPUs, networks, volumes and bind mounts go on your own docker run. You can bake sandbox.yaml into the image instead of copying it.