Daytona Sandboxes Arrive as a Component in the Convex Directory

Closing the gap between agent state and code execution

According to Daytona, agents built on Convex already benefit from durable conversations and reactive state, with every open browser tab agreeing about what is happening without custom sync code. The gap appears when an agent needs to run something, such as executing code it just wrote, working with a filesystem or starting a dev server. At that point it has to leave the Convex world and call out to raw infrastructure.

The new component, @daytona/convex, is meant to remove that step. It is listed in the Convex component directory and is installed into a backend like any other component, according to Daytona.

How the pairing works

Daytona describes Convex's core idea as state being one consistent, subscribable thing, with the database acting as the sync engine. Daytona's own approach is that agent code should run on real, isolated, disposable machines. The component combines the two: each sandbox and each command execution becomes a row in reactive Convex tables.

Daytona says this has practical effects:

• A command's status changes from running to completed in the UI as soon as it exits, with no polling and no websocket plumbing.
• A user can refresh the page mid-job and see progress resume where it was, because it never lived in the connection.
• A second tab, a teammate's browser and an admin dashboard all see the same execution history.

In Daytona's framing, execution stops being a side effect the UI chases and becomes state the UI simply reads.

What the component includes

From Daytona, the component offers sandboxes that start from snapshots or any Docker image, shell and code execution, filesystem operations, signed preview URLs for anything serving a port, and lifecycle controls such as auto-stop and auto-delete so experiments clean up after themselves.

From Convex, it draws on live queries, durable execution records, multi-client consistency and the scheduler. The scheduler powers runBackground, Daytona's approach to long-running work. A developer starts a command and immediately gets an execution ID back, then logs stream into the row while a chain of lightweight scheduled functions supervises the job. According to Daytona, no action is held open and there is no 10-minute ceiling.

Setup and an example app

Installation takes an npm install of @daytona/convex, setting a DAYTONA_API_KEY environment variable through the Convex CLI, and registering the component in convex/convex.config.ts. Daytona's sample shows a code-interpreter tool in a few lines: an action creates a sandbox with an autoStopInterval of 15 and then calls runCode with Python. Subscribing to daytona.listExecutions from the frontend renders the run history live, the company says.

To test how far the pattern goes, Daytona built an AI app builder on top of it. A user describes an app in one prompt, the LLM's code streams into the page as reactive state, and the finished app runs in an iframe through a Daytona preview URL. Daytona says the result is refresh-proof, works across multiple tabs and takes about 200 lines in total.

What it means for developers

For teams already using Convex, the component offers a way to add sandboxed code execution without building separate infrastructure or a custom layer to track job status. Daytona points developers to the Convex component directory, npm and the source repository, along with a guide and example app titled "Build an AI App Builder with Convex and Daytona". Users need API keys from both the Daytona dashboard and Convex.