Skip to main content
The kubernetes machine provider reaches a running pod, by name, through kubectl exec, and the machine runtime runs captured programs in it. You create the pod; Mirage only runs programs in it. Python SDK and Node.

Installation

Install kubectl and sign it in to the cluster. Mirage uses the credentials and context kubectl already has. Create a pod that stays running:

Nitro Sandboxes on EKS

To run the pod in an AWS Nitro Sandbox, a lightweight VM with its own kernel, set the runtime class on it. This needs Kubernetes 1.36 or later.
Mirage needs exec and stdin, so use isolated-sandbox. A confidential-sandbox pod denies them, and programs cannot run in it.

Usage

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

Configuration

Connecting the workspace

Pick a mount_type. With ssh, the pod needs sshfs and access to /dev/fuse. With fuse, put sandbox.yaml in the pod and start Mirage:

Notes

  • The pod’s phase must be Running.
  • The working directory and environment travel on the kubectl command line, where other users of the host can see them in ps.
  • A run whose connection to the pod drops ends with status 129.
  • Lines sent to one pod share its files and processes. Give each tenant its own pod.