I'm Kacper from Vstorm. We build AI agents for production and open-source our tooling as Pydantic AI libraries.
pydantic-ai-backend (github.com/vstorm-co/pydantic-ai-backend) provides file storage and code execution backends for Pydantic AI agents. We've supported Docker sandboxes since day one. In v0.1.12, we added Daytona as an alternative.
A few technical points:
1. *The sub-90ms number.* Daytona pre-provisions VMs and keeps them warm. "Create sandbox" is essentially "assign a pre-warmed VM" — no image pulls, no container creation, no daemon startup. The bottleneck is network latency to their API, not infrastructure setup.
2. *BaseSandbox abstraction.* We extracted an abstract base class that both Docker and Daytona implement: `execute()`, `_read_bytes()`, `write()`, `edit()`, `is_alive()`, `stop()`. Adding Daytona meant implementing 4 methods. Zero changes to agent code or toolsets.
3. *Native file APIs.* Docker pipes file I/O through shell commands (`docker exec cat ...`). Daytona has direct upload/download APIs via their SDK. Measurably faster for binary files.
4. *CompositeBackend.* You can route by path prefix — read source files from local filesystem (fast, no overhead), execute untrusted code in Daytona (isolated). The agent doesn't know — it calls `read_file()` and `execute()`, and the composite routes each call to the right backend.
5. *Docker isn't going away.* For local development and self-hosted setups, Docker is still the right choice (free, custom runtimes, no external dependency). Daytona is for cloud-native deployments where Docker daemon access is impractical — CI/CD, serverless, Kubernetes without privileged containers.
pydantic-ai-backend (github.com/vstorm-co/pydantic-ai-backend) provides file storage and code execution backends for Pydantic AI agents. We've supported Docker sandboxes since day one. In v0.1.12, we added Daytona as an alternative.
A few technical points:
1. *The sub-90ms number.* Daytona pre-provisions VMs and keeps them warm. "Create sandbox" is essentially "assign a pre-warmed VM" — no image pulls, no container creation, no daemon startup. The bottleneck is network latency to their API, not infrastructure setup.
2. *BaseSandbox abstraction.* We extracted an abstract base class that both Docker and Daytona implement: `execute()`, `_read_bytes()`, `write()`, `edit()`, `is_alive()`, `stop()`. Adding Daytona meant implementing 4 methods. Zero changes to agent code or toolsets.
3. *Native file APIs.* Docker pipes file I/O through shell commands (`docker exec cat ...`). Daytona has direct upload/download APIs via their SDK. Measurably faster for binary files.
4. *CompositeBackend.* You can route by path prefix — read source files from local filesystem (fast, no overhead), execute untrusted code in Daytona (isolated). The agent doesn't know — it calls `read_file()` and `execute()`, and the composite routes each call to the right backend.
5. *Docker isn't going away.* For local development and self-hosted setups, Docker is still the right choice (free, custom runtimes, no external dependency). Daytona is for cloud-native deployments where Docker daemon access is impractical — CI/CD, serverless, Kubernetes without privileged containers.
Install: `pip install pydantic-ai-backend[daytona]`
Happy to discuss the architecture or the backend abstraction design.