Cloud Workers (Daytona)
Relevant source files
The following files were used as context for generating this wiki page:
Cloud Workers (Daytona) is a remote execution environment for OpenWork agents, providing managed hosting on top of the open-source core. By integrating with the Daytona cloud sandbox infrastructure, OpenWork allows users to deploy "always-on" AI workers that handle repetitive tasks without requiring a local desktop app to be running continuously.
Sources: ee/apps/landing/public/llms.txt:6-14, evals/cloud-worker-flows.md:1-5
Architecture and Infrastructure
The system utilizes Daytona as the underlying cloud sandbox infrastructure, specifically leveraging EU-based instances for worker execution. These sandboxes provide isolated environments where agents can run tools, manage files, and interact with external APIs via MCP (Model Context Protocol).
Sources: ee/apps/landing/lib/agent-markdown.ts:60-65, ee/apps/den-api/src/env.ts:160-200
Provisioning Flow
When a user launches a cloud worker, the Den API initiates an asynchronous provisioning process. The environment can be configured in various modes, with daytona being the production-ready mode that creates real sandboxes.
Key Components
Environment Configuration
The system relies on extensive environment variables to manage the Daytona integration, including resource limits, timeouts, and network settings.
| Variable | Description | Default |
|---|---|---|
DAYTONA_API_URL | Base URL for Daytona API | https://app.daytona.io/api |
DAYTONA_SANDBOX_CPU | Reserved CPU cores for worker | 2 |
DAYTONA_SANDBOX_MEMORY | Reserved RAM (GB) for worker | 4 |
DAYTONA_SANDBOX_DISK | Reserved disk space (GB) | 8 |
DAYTONA_SANDBOX_IMAGE | Base container image | node:20-bookworm |
Sources: ee/apps/den-api/src/env.ts:160-200
Worker Lifecycle Management
The registerWorkerCoreRoutes function defines the API surface for managing the lifecycle of Daytona workers.
- Creation: Handled by
POST /v1/workers. For cloud destinations, it triggerscontinueCloudProvisioning. - Status Tracking: The system polls
getLatestWorkerInstanceto retrieve region, provider, and preview URLs. - Cleanup:
DELETE /v1/workers/:idtriggersdeleteWorkerCascade, which removes tokens and provider-specific resources in Daytona.
Sources: ee/apps/den-api/src/routes/workers/core.ts:140-175, ee/apps/den-api/src/routes/workers/core.ts:440-475
Data and Workspace Flow
Cloud workers operate on a "remote-first" data model. Tool calls and file results are confined to the remote Daytona workspace to ensure no local paths are leaked during task execution.
Sources: evals/cloud-worker-flows.md:45-55
Authentication and Access
Access to Daytona workers is managed via scoped tokens. When a worker is created, three distinct tokens are generated:
- Owner/Host Token: For administrative control of the sandbox.
- Client Token: For the desktop app to interact with the worker.
- Activity Token: For tracking worker actions and logs.
Sources: ee/apps/den-api/src/routes/workers/core.ts:245-275
Task Execution and Recovery
Once connected, workers function as standard OpenWork workspaces but execute in the cloud. The system is designed to handle failures such as stopped or unreachable sandboxes by transitioning the UI to a clear "unreachable" state rather than spinning indefinitely.
Worker Token Refresh
The desktop app can periodically refresh worker metadata and tokens. This ensures that even if the Electron app is restarted, the connection to the Daytona sandbox remains stable or reconnects cleanly.
Sources: evals/cloud-worker-flows.md:60-80
Conclusion
Cloud Workers (Daytona) represent the bridge between local-first agent workflows and always-available automation. By offloading execution to Daytona's sandbox infrastructure, OpenWork provides a compliance-ready and scalable environment for multi-step agentic tasks while maintaining the security boundaries of a remote workspace.
Sources: ee/apps/landing/public/llms.txt:10-25, ee/apps/landing/lib/agent-markdown.ts:10-20