Skip to main content
The ssh machine provider reaches a machine running sshd, and the machine runtime runs captured programs on it. Anything you can already ssh into works, with nothing to install on it. You run the machine; Mirage only runs programs on it. Python SDK and Node.

Installation

Usage

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

Connecting the workspace

A program on the machine opens workspace files at the same paths as in Mirage, so the machine must see the mounts there. With mount_type: ssh, Mirage serves every mount over the runtime’s own connection and the machine mounts each with sshfs, as for Docker. The machine needs sshfs, and passwordless sudo for a mountpoint its user cannot create (/data). Without mount_type, two ways: Files already on the machine. Mount the machine’s directory with the ssh VFS at a prefix equal to its path there. The same path then names the same file on both sides, with nothing to install:
Any other mount (S3, Slack and so on). Install Mirage and fuse3 on the machine. Write the same mounts at the same paths into sandbox.yaml, and start Mirage with it there:
Nothing checks that the paths match; a mismatch shows only when a program misses a file. For a friendlier name, put or link the directory at that path on the machine: Mirage never rewrites paths. A program on the machine opens its files directly, outside this workspace’s mount modes and permissions.

Runtime behavior

Notes

  • host is also the address unless hostname overrides it; port, username, identity_file, private_key and timeout are optional. Authentication is a key or an agent, never a password.
  • private_key takes the key’s own text rather than a path, so a credential pointer can read it from a secret store.
  • The machine’s login shell must be POSIX-compatible. Commands use the session’s working directory and environment.
Host keys are not verified, so treat the network path to the machine as trusted.