Open-source infrastructure for securely running AI-generated code in isolated sandboxes that start in milliseconds, with SDKs for Python, TypeScript, and other languages, persistent snapshots, and an optional managed cloud.
by Daytona · submitted by JPette1783·added 2026-06-05·
Daytona is purpose-built to execute arbitrary, AI-generated code; only run untrusted code inside its isolated sandboxes, never on the host., Each sandbox has its own kernel, filesystem, and network stack, but sandboxes can make outbound network requests unless network limits are configured., Sandboxes support computer use, Git operations, and command execution; scope what an agent can do and review declarative builder configurations before use., Self-hosting runs runner compute nodes and Docker services that need elevated host privileges; isolate the deployment from production systems., Persistent snapshots retain sandbox filesystem state across sessions, which can preserve secrets or sensitive files written during execution.
Privacy notes
Using the managed cloud sends your code, files, and execution data to Daytona-operated infrastructure; review their terms before processing sensitive data., The platform emits OpenTelemetry metrics, log streaming, and audit logs that can capture command output and activity., API keys grant access to your sandboxes and organization; store them as secrets and never commit them to source control., Self-hosting keeps execution data on your own infrastructure but you become responsible for log retention, access control, and isolation.
Author
Daytona
Submitted by
JPette1783
Claim status
unclaimed
Last verified
2026-06-05
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
63
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Needs review
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
No reviewed flag detected in metadata.
Pending
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
5 safety and 4 privacy notes across 5 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
5 areas
SafetyExecution & processesDaytona is purpose-built to execute arbitrary, AI-generated code; only run untrusted code inside its isolated sandboxes, never on the host.
SafetyNetwork accessEach sandbox has its own kernel, filesystem, and network stack, but sandboxes can make outbound network requests unless network limits are configured.
SafetyPermissions & scopesSandboxes support computer use, Git operations, and command execution; scope what an agent can do and review declarative builder configurations before use.
SafetyPermissions & scopesSelf-hosting runs runner compute nodes and Docker services that need elevated host privileges; isolate the deployment from production systems.
SafetyCredentials & tokensPersistent snapshots retain sandbox filesystem state across sessions, which can preserve secrets or sensitive files written during execution.
PrivacyLocal filesUsing the managed cloud sends your code, files, and execution data to Daytona-operated infrastructure; review their terms before processing sensitive data.
PrivacyExecution & processesThe platform emits OpenTelemetry metrics, log streaming, and audit logs that can capture command output and activity.
PrivacyCredentials & tokensAPI keys grant access to your sandboxes and organization; store them as secrets and never commit them to source control.
PrivacyPermissions & scopesSelf-hosting keeps execution data on your own infrastructure but you become responsible for log retention, access control, and isolation.
Disclosure: editorial
Safety notes
Daytona is purpose-built to execute arbitrary, AI-generated code; only run untrusted code inside its isolated sandboxes, never on the host.
Each sandbox has its own kernel, filesystem, and network stack, but sandboxes can make outbound network requests unless network limits are configured.
Sandboxes support computer use, Git operations, and command execution; scope what an agent can do and review declarative builder configurations before use.
Self-hosting runs runner compute nodes and Docker services that need elevated host privileges; isolate the deployment from production systems.
Persistent snapshots retain sandbox filesystem state across sessions, which can preserve secrets or sensitive files written during execution.
Privacy notes
Using the managed cloud sends your code, files, and execution data to Daytona-operated infrastructure; review their terms before processing sensitive data.
The platform emits OpenTelemetry metrics, log streaming, and audit logs that can capture command output and activity.
API keys grant access to your sandboxes and organization; store them as secrets and never commit them to source control.
Self-hosting keeps execution data on your own infrastructure but you become responsible for log retention, access control, and isolation.
Prerequisites
A Daytona Cloud account and API key for the managed service, or self-hosted infrastructure for the open-source platform.
Python 3.8+ for the `daytona` SDK or Node.js 18+ for the `@daytona/sdk` TypeScript SDK.
Docker and Docker Compose to run supporting services (PostgreSQL, Redis) when self-hosting.
Nix with flakes enabled or a devcontainer-compatible editor for local development of the platform itself.
## Overview
Daytona is open-source infrastructure for securely executing AI-generated code.
It provides sandboxes described as full composable computers with complete
isolation — a dedicated kernel, filesystem, network stack, and allocated vCPU,
RAM, and disk — that spin up in well under a second.
It is aimed at agent builders who need a safe place to run untrusted or
model-generated code at scale. You interact with sandboxes through SDKs, a REST
API, and a CLI, and with humans through a dashboard, web terminal, SSH, and VNC.
Daytona is released under AGPL-3.0; a managed cloud with usage-based pricing is
also available for teams that do not want to self-host.
## Features
- Isolated sandboxes with millisecond start times and per-sandbox kernel,
filesystem, and network stack.
- Persistent snapshots for stateful agent operations across sessions.
- SDKs for Python (`pip install daytona`) and TypeScript
(`npm install @daytona/sdk`), plus Ruby and Go.
- REST API and CLI for programmatic and scripted control.
- Built-in Git operations, LSP support, computer use, and MCP server
integration.
- Organization governance: API keys, audit logs, and billing controls.
## Use Cases
- Give a coding agent a safe sandbox to run and test generated code.
- Execute untrusted user-submitted code without exposing host systems.
- Provide reproducible, snapshot-backed environments for long-running agents.
- Self-host execution infrastructure to keep code and data on your own systems.
## Disclosure
Editorial listing. No paid placement or affiliate relationship. Daytona's core
platform is open source (AGPL-3.0); the managed cloud is a separate paid,
usage-based service.
About this resource
Overview
Daytona is open-source infrastructure for securely executing AI-generated code.
It provides sandboxes described as full composable computers with complete
isolation — a dedicated kernel, filesystem, network stack, and allocated vCPU,
RAM, and disk — that spin up in well under a second.
It is aimed at agent builders who need a safe place to run untrusted or
model-generated code at scale. You interact with sandboxes through SDKs, a REST
API, and a CLI, and with humans through a dashboard, web terminal, SSH, and VNC.
Daytona is released under AGPL-3.0; a managed cloud with usage-based pricing is
also available for teams that do not want to self-host.
Features
Isolated sandboxes with millisecond start times and per-sandbox kernel,
filesystem, and network stack.
Persistent snapshots for stateful agent operations across sessions.
SDKs for Python (pip install daytona) and TypeScript
(npm install @daytona/sdk), plus Ruby and Go.
REST API and CLI for programmatic and scripted control.
Built-in Git operations, LSP support, computer use, and MCP server
integration.
Organization governance: API keys, audit logs, and billing controls.
Use Cases
Give a coding agent a safe sandbox to run and test generated code.
Execute untrusted user-submitted code without exposing host systems.
Provide reproducible, snapshot-backed environments for long-running agents.
Self-host execution infrastructure to keep code and data on your own systems.
Disclosure
Editorial listing. No paid placement or affiliate relationship. Daytona's core
platform is open source (AGPL-3.0); the managed cloud is a separate paid,
usage-based service.
Open-source infrastructure for securely running AI-generated code in isolated sandboxes that start in milliseconds, with SDKs for Python, TypeScript, and other languages, persistent snapshots, and an optional managed cloud.
Open-source infrastructure for running AI-generated code in secure, isolated cloud sandboxes, with Python and JavaScript SDKs, a Code Interpreter package, and self-hosting options.
Apache-2.0 sandbox runtime and SDK suite for AI agents, with Python, Java/Kotlin, JavaScript/TypeScript, C#/.NET, and Go SDKs, Docker and Kubernetes runtimes, OpenSandbox MCP server, CLI, code interpreter, filesystem and command tools, network policy, credential vault, and secure container runtime guidance.
Open-source project behind CodeLayer, an IDE for orchestrating AI coding agents built on Claude Code, with keyboard-first workflows, team context engineering, and parallel Claude Code sessions across worktrees and cloud workers.
✓Daytona is purpose-built to execute arbitrary, AI-generated code; only run untrusted code inside its isolated sandboxes, never on the host.
Each sandbox has its own kernel, filesystem, and network stack, but sandboxes can make outbound network requests unless network limits are configured.
Sandboxes support computer use, Git operations, and command execution; scope what an agent can do and review declarative builder configurations before use.
Self-hosting runs runner compute nodes and Docker services that need elevated host privileges; isolate the deployment from production systems.
Persistent snapshots retain sandbox filesystem state across sessions, which can preserve secrets or sensitive files written during execution.
✓E2B is built to execute arbitrary, AI-generated code; run such code only inside its isolated cloud sandboxes, never directly on a developer machine.
Sandbox network and filesystem access depend on configuration; review and restrict sandbox capabilities before running untrusted code.
Generated code can still perform destructive or unexpected actions within a sandbox, so treat sandbox outputs and side effects with caution.
Self-hosting deploys cloud infrastructure via Terraform that you are responsible for securing, patching, and isolating from production systems.
✓OpenSandbox exposes sandbox creation, command execution, file read/write/delete/search/move, endpoint exposure, metrics, and lifecycle control; restrict who can call those tools and which images they can run.
MCP clients can ask OpenSandbox to write files, run commands, install dependencies, expose ports, and kill or renew sandboxes. Require approval gates for high-impact workloads.
Container and Kubernetes sandboxes are isolation boundaries, not magic safety guarantees; configure seccomp, capabilities, mounts, network egress, resource limits, image trust, and cleanup behavior.
Credential Vault can reduce secret exposure, but injected credentials still need least privilege, rotation, audit logging, and outbound network controls.
Security policy says only the latest release and main branch are actively supported with security updates; pin versions and plan upgrades accordingly.
✓CodeLayer orchestrates AI coding agents that edit files and run commands in your repositories, so it inherits the execution risks of the underlying Claude Code agent.
MultiClaude runs multiple Claude Code sessions in parallel across git worktrees; review changes per worktree before merging to avoid conflicting or unreviewed edits.
Remote cloud workers can run agent sessions on external infrastructure; understand where code executes before enabling them.
Scaling agent workflows to a whole team increases the blast radius of automated edits, so keep human review and branch protections in place.
Privacy notes
✓Using the managed cloud sends your code, files, and execution data to Daytona-operated infrastructure; review their terms before processing sensitive data.
The platform emits OpenTelemetry metrics, log streaming, and audit logs that can capture command output and activity.
API keys grant access to your sandboxes and organization; store them as secrets and never commit them to source control.
Self-hosting keeps execution data on your own infrastructure but you become responsible for log retention, access control, and isolation.
✓On the managed cloud, your code and execution data are sent to and run on E2B-operated infrastructure; review their privacy terms before processing sensitive data.
API keys grant access to your sandboxes; store them in environment variables or a secrets manager and never commit them to source control.
Data passed into a sandbox (files, inputs, environment variables) lives in that sandbox for its lifetime; avoid sending secrets you do not need there.
Self-hosting keeps execution data on your own infrastructure, making log retention, access control, and isolation your responsibility.
✓Sandbox workloads can process source code, prompts, tool arguments, command output, uploaded files, generated files, environment variables, credentials, logs, metrics, endpoints, and network destinations.
The MCP server and CLI can store API keys, domain configuration, sandbox IDs, command history, file paths, and endpoint details in local configs, shell history, logs, or MCP client state.
Kubernetes, Docker registries, ingress gateways, credential vaults, OpenTelemetry or audit systems, and hosted OpenSandbox endpoints may retain workload metadata and outputs depending on deployment.
Do not run untrusted code with access to private networks, production credentials, customer data, or broad egress without isolation, monitoring, and retention rules.
✓Because it builds on Claude Code, repository code and context are sent to Anthropic's API to power the agent.
Remote cloud workers process your code and context on external infrastructure; review the provider's terms before sending private code.
Any API keys or credentials used by Claude Code and CodeLayer should be stored as secrets, not committed to source control.
Team and context-engineering features can share prompts, context, and workflow data across collaborators, so avoid placing secrets in shared context.
Prerequisites
A Daytona Cloud account and API key for the managed service, or self-hosted infrastructure for the open-source platform.
Python 3.8+ for the `daytona` SDK or Node.js 18+ for the `@daytona/sdk` TypeScript SDK.
Docker and Docker Compose to run supporting services (PostgreSQL, Redis) when self-hosting.
Nix with flakes enabled or a devcontainer-compatible editor for local development of the platform itself.
An E2B account and API key from the dashboard, set as the `E2B_API_KEY` environment variable, for the managed cloud.
Python 3.8+ for the `e2b` / `e2b-code-interpreter` SDK, or Node.js 18+ for the `e2b` / `@e2b/code-interpreter` SDK.
Self-hosting requires Terraform and a supported cloud provider to deploy the sandbox infrastructure.
Python 3.10 or newer for the Python SDK, CLI, and MCP package, or the selected Java/Kotlin, JavaScript/TypeScript, .NET, or Go runtime for another SDK.
Docker for local execution, or Kubernetes and cluster access for distributed scheduling.
An OpenSandbox server endpoint, protocol, API key, sandbox image, timeout, network policy, and cleanup policy.
Credential Vault and egress policy design before letting agent workloads reach external APIs or private services.
Claude Code, since CodeLayer is built on top of it and orchestrates Claude Code sessions.
An Anthropic account or API access for the underlying Claude Code agent.
A recent CodeLayer build from the project's GitHub releases or the waitlist for early access.
Git, since parallel-session workflows rely on worktrees.