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
- Python
- TypeScript
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.
- Python
- TypeScript
- YAML
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 andfuse3. 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.yamldecides. - 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
ddandbase64(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.