Daytona backend (Linux VM sandboxes) #61

Summary

Add a daytona backend (host/backends/daytona.sh) that runs boxery VMs as Daytona Linux VM sandboxes. Daytona is the most widely used sandbox provider that has ssh access (about 4.9M npm + 9.2M PyPI SDK downloads a month, October 2026), so it would reach the most users.

Fit

Daytona defaults to containers, but its Linux VM class gives boxery what it needs:

• VM sandboxes come from a VM snapshot (daytona-vm-small/medium/large, or your own with sandboxClass: "linux-vm"). Optional kvm: true if the org has it enabled.
• Fork duplicates a started VM's filesystem and memory into an independent sandbox. Forks of forks work. A parent can't be deleted while it has live fork children, which breaks boxery's "images are independent" rule. So images should be filesystem snapshots, not forks.
• Snapshot from sandbox: a cold (filesystem) snapshot needs the sandbox stopped; a hot one (includeMemory: true) captures RAM. boxery images are disk-only, so capture of a running VM must stop it briefly, as Lima does.
• Stop/start is a real shutdown (memory dropped); pause/resume keeps memory. boxery's stop maps to stop.
• Auto-pause defaults to 60 min for VMs. Set the interval to 0.
• Computer use / VNC is built in, but boxery ships its own desktop (XFCE + TigerVNC on :1), so it isn't needed.

Open questions

• SSH: Daytona's ssh is token-based (ssh <token>@ssh.app.daytona.io, tokens expire after 60 min by default) through a shared gateway. Does it allow -L/-R forwarding? boxery needs a guest→host path for the LLM proxy, and lease fencing needs the guest's own sshd. If the gateway forwards ports, use the exe.dev pattern (loopback sshd plus a supervised tunnel). Otherwise run the tunnel from the guest, or use Daytona's port previews.
• Base image: VM snapshots can't be built with the declarative builder (containers only). Build by booting a stock VM snapshot, applying image/base-user-data.yaml over ssh, stopping, and snapshotting it, as build-base does on exe.dev.
• Sizes: the default VM snapshots are small (largest: 4 vCPU / 8 GiB / 10 GiB disk). Can custom VM snapshots set bigger resources, and resize a disk?
• Rate limits, regions, and whether stopped VM disks expire.

Done when

• boxery-host init --backend daytona + build-base, then new, snap/revert, fork, new --from, stop/start and rm work end to end on a Daytona account.
• Offline tests against a fake Daytona API, like test/shell/host-exe-backend.sh.
• host/backends/README.md documents it.

Related: the boat.dev backend (#60); the exe.dev backend (#30).

This issue was generated by Claude Code using Claude Opus 5.5