Current evidence
A connected encrypted profile completed create, idempotent replay, get, persistent commands, file write/read, list, delete, and deletion confirmation on private staging on July 28, 2026.
Create a Daytona sandbox
Authenticate to Wildflower Computer with its bearer key and send yourDaytona API key separately in X-Provider-Api-Key. No additional provider routing header is required.
curl --fail-with-body "$WILDFLOWER_URL/v1/sandboxes" \ -H "Authorization: Bearer $WILDFLOWER_API_KEY" \ -H "X-Provider-Api-Key: $PROVIDER_API_KEY" \ -H "Content-Type: application/json" \ --data '{ "provider": "daytona", "image": "ubuntu:22.04", "timeout": 300}'Capabilities and behavior
| Concern | Current behavior |
|---|---|
| Image | The image field is a container image. The adapter generates a one-line Dockerfile using that image. |
| Lifetime | The API accepts seconds and the adapter rounds them up to whole Daytona TTL minutes. |
| Execution | Daytona returns combined command output. The adapter places it in stdout and returns an empty stderr. |
| Credential | Daytona API key; resolved from a project profile or supplied as an ephemeral inline override. |
Current limitations
- Timeout precision is one minute after adapter rounding.
- Standard output and standard error are not separable in the synchronous Daytona command response.
- The sandbox remains attached to Daytona for its complete lifecycle.
Tested compatibility
The adapter tests pin the request and response shapes used by Wildflower Computer. These labels describe the tested upstream contract; callers do not select a provider API version.
Use a generated SDK
Every generated client exposes the same lifecycle and typed provider creation inputs. The packages are generated from the versioned OpenAPI document and source model.
- Use the TypeScript SDK with Daytona
- Use the Python SDK with Daytona
- Use the Rust SDK with Daytona
- Use the Go SDK with Daytona
- Use the Zig SDK with Daytona