Run Daytona sandboxes from Convex actions with reactive state: execute code, run shell commands, and manage files with results queryable in real time.
npm install @daytona/convexThe Daytona component wraps the Daytona sandbox API in a typed Convex client, recording every sandbox and command execution in component-namespaced tables that your queries and mutations can subscribe to reactively. It lets Convex actions create isolated sandboxes, run shell commands and Python/JavaScript code, manage files, and fetch signed preview URLs without requiring the Node.js runtime. State like exit codes, output, and sandbox lifecycle is queryable from standard Convex queries rather than polled from the Daytona API directly.
The Daytona component for Convex provides a runCode method that accepts a sandboxId, code string, and language. Call it inside a Convex action to execute Python in an isolated Daytona sandbox and get back the result and exit code. Sandbox state and execution history are written to component tables automatically, so downstream queries can read status without additional API calls.
Use the @daytona/convex component to create a sandbox per session with createSandbox, then call runCode or run to execute user-submitted code. Execution records transition from running to completed or failed in reactive Convex tables, letting your UI subscribe to live status via useQuery without any polling logic.
The Daytona component exposes a run method that accepts a sandboxId, command string, working directory, and timeout. It can be called from a Convex action and automatically restarts a stopped or archived sandbox before executing. Results including exit code and output are stored in the component's executions table and are queryable via listExecutions or getExecution.
Pass a userKey string when calling createSandbox, run, or runCode to associate sandboxes and executions with a specific user or agent identifier. Use listSandboxes with the same userKey inside a Convex query function to return only that user's sandboxes. Authenticate callers in your own query or action using ctx.auth before passing the resolved identity to the component.
No. The @daytona/convex component communicates with the Daytona REST API using plain fetch in Convex's default runtime. There is no need for 'use node' directives, and the component carries no heavy SDK dependencies, which keeps cold start times low.
Every call to run or runCode writes an execution record to a component-managed table with status transitions from running to completed or failed. Output is stored up to 64 KB per record, while the action return value carries up to 4 MB. These records are queryable via listExecutions and getExecution without making any Daytona API calls.
Convex actions time out after 10 minutes. The timeoutSeconds parameter on run and runCode defaults to 540 seconds and is capped at 570 seconds. For jobs that take longer, start a background process in the sandbox using nohup and poll its status with follow-up run calls.
Pass a userKey string to createSandbox, run, or runCode to associate resources with a specific user or agent. Because Convex components cannot access ctx.auth directly, authenticate callers in your own query or action function, resolve the user identity, and forward it as the userKey value when calling component methods.
Sandboxes can be created from a named snapshot or a Docker image. When using an image, you can specify cpu, memory, and disk resources. Snapshot-based sandboxes use the resource configuration defined in the snapshot. You can also set autoStopInterval to pause idle sandboxes and autoDeleteInterval to control automatic deletion, which helps manage costs.