Add exec-sandbox deployment (self-hosted QEMU microVMs)
Summary
Proposing exec-sandbox as a new AbstractDeployment backend for SWE-ReX. It runs code in ephemeral QEMU microVMs with hardware-level isolation (KVM on Linux, HVF on macOS) — self-hosted, no cloud account needed.
Why
- Self-hosted — ModalDeployment and FargateDeployment require cloud accounts. DockerDeployment requires Docker. exec-sandbox runs on bare metal with just QEMU. Data never leaves the machine.
- macOS + Linux — HVF on macOS, KVM on Linux. Docker alternative for macOS dev machines without Docker Desktop.
- Fast — ~1-2ms from warm pool, ~200ms from memory snapshots.
- VM isolation — Hardware-level boundary vs Docker process isolation.
- Apache-2.0
How it maps
exec-sandbox is a Python library with an async API. Following the Daytona deployment pattern (PR #191):
class ExecSandboxDeploymentConfig(BaseModel):
type: Literal["exec_sandbox"] = "exec_sandbox"
language: str = "raw"
memory_mb: int = 512
def get_deployment(self) -> AbstractDeployment:
from .exec_sandbox import ExecSandboxDeployment
return ExecSandboxDeployment.from_config(self)
The deployment would:
start() — Boot a QEMU microVM via Scheduler.session(), then start the swerex-remote server inside it via session.exec()
stop() — Close the session (VM is ephemeral, auto-destroyed)
runtime — Return a RemoteRuntime connected to the swerex-remote server inside the VM
is_alive() — Check VM + runtime health
The key question is how to expose the swerex-remote HTTP server running inside the VM. exec-sandbox supports port forwarding via expose_ports, which could map the server port to the host.
Open questions
- Port forwarding —
swerex-remote needs an HTTP endpoint reachable from the host. exec-sandbox's expose_ports feature can handle this, but the exact wiring needs validation.
- Base image — The
swerex-remote binary would need to be available inside the VM. Options: pre-bake it into the QEMU image, or pip install at session start.
Links
Happy to submit a PR if there's interest.
Add exec-sandbox deployment (self-hosted QEMU microVMs)
Summary
Proposing exec-sandbox as a new
AbstractDeploymentbackend for SWE-ReX. It runs code in ephemeral QEMU microVMs with hardware-level isolation (KVM on Linux, HVF on macOS) — self-hosted, no cloud account needed.Why
How it maps
exec-sandbox is a Python library with an async API. Following the Daytona deployment pattern (PR #191):
The deployment would:
start()— Boot a QEMU microVM viaScheduler.session(), then start theswerex-remoteserver inside it viasession.exec()stop()— Close the session (VM is ephemeral, auto-destroyed)runtime— Return aRemoteRuntimeconnected to theswerex-remoteserver inside the VMis_alive()— Check VM + runtime healthThe key question is how to expose the
swerex-remoteHTTP server running inside the VM. exec-sandbox supports port forwarding viaexpose_ports, which could map the server port to the host.Open questions
swerex-remoteneeds an HTTP endpoint reachable from the host. exec-sandbox'sexpose_portsfeature can handle this, but the exact wiring needs validation.swerex-remotebinary would need to be available inside the VM. Options: pre-bake it into the QEMU image, orpip installat session start.Links
Happy to submit a PR if there's interest.