Skip to main content
The Daytona integration connects Kestrel to your Daytona organization, enabling sandbox, snapshot, and volume lifecycle events to trigger workflows and giving AI agents access to sandbox state, snapshots, and volumes. Daytona delivers sandbox, snapshot, and volume lifecycle events to Kestrel through a webhook you register in the Daytona dashboard. Kestrel verifies every delivery against the webhook’s signing secret before it can fire a workflow.

​
Prerequisites

  • Organization Admin role in Kestrel
  • Daytona account with an organization
  • A Daytona organization API key
  • Webhooks enabled for your Daytona organization

​
Setup

1

Create an API key

In the Daytona dashboard, open API Keys in the left sidebar and click Create API Key (or use the CLI: daytona api-key create). Then:
  1. Enter a Key Name (e.g. kestrel).
  2. Optionally set an Expires date — leave blank for a non-expiring key, or pick a date and plan to rotate the key in Kestrel before it expires.
  3. For Permissions, choose Full Access (simplest), or choose Restricted and grant Read + Write + Delete on Sandboxes and Snapshots plus Read on Volumes. The Sandboxes preset alone is not sufficient — snapshot and volume actions require those additional grants.
  4. Click Create and copy the generated key (shown only once).
The key is sent as a bearer token to https://app.daytona.io/api to read sandbox, snapshot, and volume state and perform actions.
2

Create a webhook in Daytona

  1. In the Daytona dashboard, open Webhooks. If webhooks aren’t enabled yet, click Enable webhooks.
  2. Click Create Endpoint, give it a name, and set the Endpoint URL to the Kestrel webhook URL shown on the Integrations → Daytona connect screen (it ends in /api/webhooks/daytona).
  3. For Events, select all the sandbox, snapshot, and volume events, then click Create.
  4. Click the newly created endpoint to open its details and copy its Signing Secret.
3

Connect in Kestrel

  1. Navigate to Integrations → Daytona in your Kestrel dashboard.
  2. Paste your Daytona API key.
  3. (Optional) Set a custom API URL for self-hosted Daytona.
  4. Paste the webhook Signing Secret from the previous step.
  5. Click Connect Daytona — your Daytona organization appears as connected.
The API key grants access to your Daytona sandboxes, snapshots, and volumes. Treat it and the signing secret as secrets — Kestrel stores both encrypted.
Kestrel only fires Daytona triggers from webhook deliveries whose signature matches the signing secret you provided. To rotate the secret, update it in Daytona, then disconnect and reconnect in Kestrel with the new value.

​
How It’s Used

​
In Workflows

Trigger blocks:
  • Sandbox Created — fires when a new sandbox is created
  • Sandbox Stopped — fires when a sandbox transitions out of the started state
  • Sandbox Error — fires when a sandbox enters an error or build-failed state
  • Sandbox Archived — fires when a sandbox is archived
  • Sandbox Execution Failed — fires when a command run in a sandbox via a workflow exits non-zero
  • Snapshot Build Failed — fires when a snapshot enters an error/build-failed state
  • Volume Error — fires when a volume enters an error state
Filter triggers by sandbox and event type. Kestrel receives these as webhook deliveries from Daytona. Action blocks:
  • List Sandboxes — list the sandboxes in the organization
  • Create Sandbox — create a sandbox from a prebuilt snapshot or a Docker image (image references must carry a specific version tag or digest, e.g. python:3.12 — untagged images and latest/lts/stable are rejected by Daytona)
  • Get Sandbox — retrieve a sandbox’s state and metadata
  • Start Sandbox — start a stopped sandbox
  • Stop Sandbox — stop a running sandbox (preserves state for restart)
  • Archive Sandbox — archive a stopped sandbox to free compute while retaining disk
  • Delete Sandbox — permanently delete a sandbox (gate behind an Approval node)
  • Run Command in Sandbox — execute a shell command in a sandbox and capture exit code and output
  • Set Auto-Stop Interval — set a sandbox’s inactivity auto-stop interval for cost control
  • List Snapshots — list the snapshots in the organization
  • Create Snapshot — create a snapshot from a Docker image (the image must carry a specific version tag or digest)
  • Delete Snapshot — delete a snapshot by name or ID
  • List Volumes — list the volumes in the organization
  • Get Volume — retrieve a volume’s state
  • Create Volume — create a volume for sharing data across sandboxes
  • Delete Volume — permanently delete a volume (gate behind an Approval node)
  • Investigate Daytona — run an AI investigation of failing sandboxes, snapshots, and volumes
Daytona sandbox, snapshot, and volume selects accept template variables like {{signal.sandbox_id}}, {{signal.snapshot}}, and {{signal.volume}} from the trigger. Create Sandbox outputs sandbox_id, sandbox_name, and sandbox_state, so downstream blocks can reference a just-created sandbox with {{step_outputs.<step>.sandbox_id}}; Create Volume similarly outputs volume_id, volume_name, and volume_state. Example: A workflow triggers on a sandbox error, runs an AI investigation to diagnose the failure, posts a summary to Slack, and opens a Jira bug ticket. Example: A workflow triggers on a newly created sandbox and sets an auto-stop interval to keep idle compute costs down.

​
Disconnecting

  1. Navigate to Integrations → Daytona
  2. Click Disconnect
  3. Confirm the disconnection
This stops all Daytona workflow triggers. You can optionally remove the webhook endpoint in the Daytona dashboard too. You can reconnect at any time.