Skip to main content
The daytona machine provider reaches a running Daytona sandbox, by ID, and the machine runtime runs captured programs in it. You create and size the sandbox; Mirage only runs programs in it. Python SDK and Node.

Installation

Boot the sandbox from an image or snapshot that has what connecting the workspace needs. Set api_key in the config, or DAYTONA_API_KEY.

Usage

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

Connecting the workspace

A program in the sandbox opens workspace files at the same paths as in Mirage, so the sandbox must see the mounts there. Mirage does not serve them into a Daytona sandbox: use 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 sandbox:
  • This workspace’s mount modes and permissions do not reach those files; sandbox.yaml decides.
  • Keep the sandbox’s paths in step with the host’s mounts yourself.

Runtime behavior

Notes

  • Closing the workspace leaves the sandbox running.
  • Output comes back as the program wrote it, binary included: the sandbox base64-encodes it on the way out, so the image needs dd and base64 (Debian, Ubuntu and Alpine images have both), and output takes about a third more to transfer. Without them a line runs nothing, prints why and exits 127.
  • Sizing, GPUs, snapshots, networking, idle-stop and auto-delete stay Daytona settings. The Daytona example covers baking a snapshot and a full read and write round trip.
  • A Daytona sandbox has no timeout of its own: after a Mirage timeout, the program keeps running and billing until you stop it.