---
name: bijection-daytona
description: "Evaluate and integrate the Daytona component with Bijection."
---

# Daytona

Sandbox lifecycle and execution

- Package: @bijectionhq/daytona
- Category: Sandboxes
- Status: Included
- License: Apache-2.0
- Bijection source (repository access required): https://github.com/bijectionhq/daytona/tree/78de84a52a9046fdf8fdd8df1f5646a32fd046e6/packages/convex
- Upstream: https://github.com/daytona/integrations/tree/4f10159a3ae5faa31792bb59abaa52aeecb5546c/packages/convex
- Documentation: https://docs.bijection.com/components/using
- Directory: https://bijection.com/components/daytona

## Get the source

Bijection repository access is required. Request access at https://bijection.com/contact.

```sh
git clone https://github.com/bijectionhq/daytona.git
cd daytona
git checkout 78de84a52a9046fdf8fdd8df1f5646a32fd046e6
cd packages/convex
```

## Before using this component

Read the package README at the recorded revision for setup, dependencies, and API examples. Upstream documentation describes the original package and may differ from the Bijection adaptation. This source is included in Bijection's workspace. Catalog inclusion does not establish npm availability or runtime qualification. Check compatibility with your SDK and deployment before adoption. External providers run their own compute.

## Integration workflow

1. Read the source README and package manifest at the recorded revision.
2. Confirm the required SDK, dependency availability, and runtime compatibility.
3. Follow the component's documented setup and configuration. Never invent an npm install command from a catalog package name.
4. Keep credentials in the project's existing secret store.
5. Follow the project's execution rules for verification and report what was actually checked.

## Original upstream skill

The following guidance describes @daytona/convex. Its installation commands and APIs refer to the upstream package. Evaluate compatibility with the Bijection source separately.


> Agents: read this skill fully before writing code that uses Daytona. Follow the installation and configuration steps exactly.

# Daytona

## Instructions

The Daytona component for Convex lets you create and manage isolated Daytona sandboxes directly from Convex actions, execute shell commands and Python/other code inside them, and read/write files -- with every sandbox and execution recorded in reactive component tables. This eliminates the need to poll external APIs for execution status: your UI can subscribe to live query results that reflect sandbox state, exit codes, and output history as they change. The component talks to the Daytona REST API via plain fetch in Convex's default runtime, so no Node.js runtime or heavy SDK bundle is required.

### Installation

```bash
npm install @daytona/convex
```

Current npm version: `@daytona/convex@2.1.0`

## Use cases

- Building an AI coding agent that needs an isolated execution environment per user session, where the UI needs to show real-time status (running, completed, failed) without polling
- Implementing a code interpreter endpoint that creates a sandbox on demand, runs submitted Python or shell code, and returns structured output including exit codes
- Running long-duration ML training jobs using runBackground so the action returns immediately and a scheduler-driven poller streams logs and exit codes into queryable Convex tables
- Scoping sandboxes to individual users with the userKey option so each user's sandbox list and execution history is isolated and queryable per identity
- Serving live preview URLs for web processes running inside a sandbox, where the port is exposed and a signed URL is returned to the client

## How it works

After installing the package and registering the component in convex.config.ts via app.use(daytona), you set a DAYTONA_API_KEY environment variable on your Convex deployment. The Daytona client is instantiated once with components.daytona and used inside actions to call methods like createSandbox, run, runCode, writeFile, and getPreviewUrl. Sandboxes can be created from a named snapshot or a Docker image, with optional resource settings (cpu, memory, disk) applying only to image-based creation.

Every sandbox lifecycle event and command execution is written to internal component tables, which means listSandboxes, getSandbox, listExecutions, and getExecution are plain Convex queries that return live data without hitting the Daytona API. This is the core architectural benefit: agent and dashboard UIs drive their state from reactive queries rather than polling.

For commands that exceed the 10-minute Convex action timeout, runBackground starts the command in a sandbox session and returns an executionId immediately. A scheduler-driven poller then checks in periodically, streams logs into the execution row, and records the final exit code when the command finishes. Synchronous run and runCode calls default to a 540-second timeout and are capped at 570 seconds.

Authorization is handled in your own functions since components cannot access ctx.auth directly. The recommended pattern is to resolve a user identity in your action or query, then pass identity.subject as the userKey when creating or listing sandboxes, which scopes all bookkeeping to that user without any additional configuration.

## When NOT to use

- When a simpler built-in solution exists for your specific use case
- If you are not using Convex as your backend
- When the functionality provided by Daytona is not needed

## Resources

- [npm package](https://www.npmjs.com/package/%40daytona%2Fconvex)
- [GitHub repository](https://github.com/daytona/integrations/tree/main/packages/convex)
- [Live demo](https://github.com/daytona/integrations/tree/main/packages/convex/example)
- [Convex Components Directory](https://www.convex.dev/components/daytona/convex)
- [Convex documentation](https://docs.convex.dev)