Daytona: de gestor abierto de entornos a plataforma de sandboxes para agentes

Todo lo que hay que saber sobre daytonaio/daytona: el repositorio histórico de una plataforma que crea entornos aislados para ejecutar código generado por IA y que, desde junio de 2026, ya no recibe desarrollo público.

Qué es Daytona

Daytona proporciona infraestructura elástica y aislada para ejecutar código, en particular código generado por agentes de IA. El repositorio daytonaio/daytona contiene la implementación pública histórica y su README ofrece clientes, API, CLI y ejemplos para crear un sandbox, ejecutar un proceso y recoger el resultado.

La propuesta evolucionó. En su lanzamiento público de 2024 se presentaba como un gestor de entornos de desarrollo; la documentación actual describe sandboxes como ordenadores aislados para cargas de trabajo de agentes, con contenedores Linux por defecto y clases adicionales de máquina virtual Linux, Windows y GPU NVIDIA. Esto no equivale a que cada backend tenga las mismas capacidades o disponibilidad.

Ilustración conceptual dividida: a la izquierda una terminal retro que representa un gestor de entornos de desarrollo, a la derecha un núcleo de IA brillante conectado a microcámaras aisladas que representan un sandbox para agentes.

Hay una advertencia decisiva: el README actual afirma que, desde junio de 2026, el desarrollo central se trasladó a una base de código privada. El repositorio queda utilizable y bifurcable bajo su licencia, pero sin nuevas correcciones, publicaciones ni soporte. Por tanto, esta ficha distingue entre el código histórico daytonaio/daytona y las API, documentación y clientes actuales de daytona.

El origen: de Codeanywhere a una alternativa empresarial a Codespaces

La cobertura de The New Stack del 6 de septiembre de 2023 atribuye Daytona a los fundadores de Codeanywhere y describe el intento de ofrecer entornos de desarrollo autogestionados, incluso detrás del cortafuegos, frente a GitHub Codespaces. TechCrunch informó el 6 de noviembre de 2023 sobre una ronda presemilla de 2 millones de dólares y resumió el posicionamiento como una alternativa de nivel empresarial a Codespaces.

El repositorio público se creó el 6 de febrero de 2024. El 6 de marzo de 2024, el equipo presentó en Hacker News el lanzamiento abierto como el resultado de un recorrido de quince años. La tensión original era práctica: hacer reproducibles y remotos los entornos de desarrollo sin depender exclusivamente de un servicio de desarrollo alojado por un proveedor. Con el tiempo, el énfasis documentado se desplazó hacia aislar la ejecución de código de agentes.

El cambio a código central privado en 2026 produjo la tensión opuesta. El equipo indicó en el README que la decisión respondía a vulnerabilidades descubiertas mediante análisis estático y por IA, pero el debate público cuestionó que ocultar el código sea una respuesta adecuada a la seguridad.

Línea de tiempo digital que arranca en un nodo brillante marcado "2024" y termina en una bóveda metálica cerrada marcada "2026", con un rótulo de neón que dice "Núcleo privado" junto a un símbolo de bifurcación abierta que se desvanece.

Filosofía y principios

La documentación y las fuentes recuperadas sostienen estos principios:

Aislamiento antes que ejecución directa: un agente o aplicación crea un sandbox en vez de ejecutar código no confiable en su propio proceso o máquina.
Entornos efímeros y programables: SDK, API REST y CLI permiten crear, usar, pausar, detener o eliminar instancias mediante código.
Integración, no un agente propio: Daytona suministra el entorno de cómputo y se conecta con marcos de agentes; no pretende sustituirlos.
Separación entre plano de control y cargas de trabajo: las claves, regiones, límites de red y ciclos de vida se configuran explícitamente.

Cubo holográfico aislado en un vacío digital oscuro, con líneas de código ejecutándose en su interior mientras una malla de neón protectora rodea la cápsula, representando el aislamiento antes de la ejecución.

Es un análisis de las interfaces documentadas, no una certificación de seguridad. La garantía de aislamiento depende del tipo de sandbox y de la configuración seleccionada.

Cómo funciona

El flujo mínimo de la API es crear un cliente autenticado, solicitar un sandbox y ejecutar código dentro de él. Por ejemplo, el README muestra en Python daytona.create() y sandbox.process.code_run(...); en TypeScript usa await daytona.create() y sandbox.process.codeRun(...). La API REST equivalente crea un sandbox con POST https://app.daytona.io/api/sandbox y una cabecera Bearer.

La CLI ofrece el acceso interactivo y automatizable. daytona create inicia la creación, mientras que la referencia actual documenta controles de ciclo de vida como --auto-stop, --auto-delete, --auto-archive, --target, volúmenes y políticas de red. Los valores importan: --auto-stop 0 desactiva la parada automática; --auto-delete 0 elimina al detenerse; y un valor negativo de --auto-delete desactiva la eliminación automática.

Panel de control futurista con nodos de cómputo aislados conectados por líneas de neón púrpura y cian, y elementos holográficos que muestran controles de ciclo de vida como "auto-stop", "auto-delete" y regiones de destino.

La configuración se resuelve en este orden: parámetros explícitos en el código, variables de entorno, archivo .env y valores predeterminados. Entre las variables iniciales figuran DAYTONA_API_KEY, DAYTONA_API_URL, DAYTONA_TARGET, DAYTONA_ORGANIZATION_ID y DAYTONA_JWT_TOKEN.

Estado oficial y semioficial

El repositorio estudiado fue un proyecto oficial de Daytona, pero ya no es el núcleo público mantenido: su propio README anuncia el traslado a código privado. No se encontró un mercado público de Daytona en la URL oficial probada; https://www.daytona.io/marketplace devuelve una página de recurso movido o inexistente.

Sí hay integración oficial o semioficial verificable en el sentido limitado de paquetes y repositorios publicados por la organización: daytona/clients reúne SDK, CLI y MCP; daytona/integrations contiene paquetes para Google ADK, LangChain de análisis de datos, n8n, OpenCode y Pi. En npm, @daytona/sdk, @daytona/opencode, @daytona/pi y @daytona/n8n-nodes-daytona se atribuyen a Daytona Platforms Inc. LangChain publica @langchain/daytona y Mastra publica @mastra/daytona; son integraciones de esos proveedores, no una homologación general de la plataforma por todos los vendedores.

El ecosistema

Repositorios oficiales relacionados

daytona/clients: clientes y SDK oficiales para TypeScript, Python, Ruby, Go y Java; también agrupa CLI y MCP.
daytona/integrations: integraciones oficiales para Google ADK, LangChain de análisis de datos, n8n, OpenCode y Pi.
daytona/homebrew-tap: fórmula Homebrew oficial.
daytona/guides: ejemplos ejecutables para sandboxes.
La organización histórica daytonaio mantiene, entre otros, gráficos Helm, módulos Terraform, una fórmula Homebrew de CLI y una lista de permitidos de red; varias muestras y plugins antiguos están archivados.

Mapa de ecosistema digital: un núcleo de servidor central etiquetado con símbolos de SDK y API envía flujos de datos de neón hacia nodos de TypeScript, Python, Ruby, Go y Java, rodeado de satélites más pequeños con los logotipos de LangChain, n8n y Google ADK.

No se incluyen cifras de estrellas de estos repositorios porque no se recuperaron sus métricas individuales en esta ejecución. La relación sí está verificada por los listados de las organizaciones y los repositorios enlazados.

Bifurcaciones, extensiones y paquetes

La API de GitHub registra 5.658 bifurcaciones de daytonaio/daytona el 8 de agosto de 2026. Entre las de mayor visibilidad devueltas por el endpoint había copias como gauravsonii/daytona, Supriya0446/daytona y jamesmurdza/daytona; no se recuperó documentación que demostrase que sean puertos independientes, por lo que se clasifican únicamente como bifurcaciones.

La superficie de extensiones confirmada es el repositorio oficial daytona/integrations y los paquetes de npm citados. No se recuperó una traducción no inglesa o un puerto comunitario con relación explícita que justificase presentarlo como extensión del proyecto.

Números del repo

Medición: 8 de agosto de 2026, API de GitHub para daytonaio/daytona.

Métrica	Valor
Estrellas	72.024
Bifurcaciones	5.658
Suscriptores reales	122
Commits	2.744
Incidencias abiertas indicadas por la API	440
Creación	6 de febrero de 2024
Último envío registrado	24 de julio de 2026
Actualización de metadatos	8 de agosto de 2026
Última publicación pública	`v0.190.0`, 23 de junio de 2026

Interfaz holográfica de un repositorio de GitHub proyectada en una sala oscura, con cifras de neón flotando: "72.024 estrellas", "5.658 bifurcaciones", "2.744 commits", y un sello luminoso de "Historial público / archivado" superpuesto sobre el código.

Los principales contribuidores devueltos por la API, por contribuciones, fueron Tpuljak (661), idagelic (439), MDzaja (170), fabjanvucina (167) y stefanicjuraj (138). El total de 2.744 commits procede de la página final del enlace de paginación de la API. La respuesta no aportó lenguaje principal ni licencia en esos campos, de modo que se omiten en vez de inferirlos. open_issues_count puede incluir solicitudes de cambios abiertas; por ello no es un conteo exclusivo de incidencias. Además, watchers_count replica las estrellas en la respuesta general de GitHub; se informa subscribers_count como número de suscriptores reales.

Cómo contribuir

La guía de contribución recuperable corresponde a la etiqueta final pública v0.190.0, por lo que sirve para bifurcaciones o el código archivado, no como promesa de aceptación por el producto actual:

Para trabajo central, discutir primero en Slack y crear o localizar una incidencia asociada.
Crear una bifurcación, mantener un cambio enfocado por solicitud de cambios y rebasar contra main con git rebase.
Añadir pruebas funcionales o de integración y documentación.
Compactar el trabajo en un commit descriptivo y firmarlo con DCO: git commit --signoff --message "This is the commit message".
Para comandos, ejecutar ./hack/generate-cli-docs.sh; para cambios de especificación de API, ./hack/swagger.sh.
Usar Yarn para dependencias de Node y ejecutar golangci-lint run.

Terminal de desarrollador en un entorno oscuro de alta tecnología, mostrando un comando git commit --signoff resaltado en verde y cian junto a una insignia holográfica de certificado de origen del desarrollador (DCO).

La guía histórica aceptaba solicitudes de cambios en borrador y afirmaba que las fusiones a main generaban una publicación. El aviso actual de no haber futuras publicaciones invalida esa expectativa para el repositorio original.

Guía rápida de uso

Instalación y primer arranque

Para una integración nueva, el README histórico documenta los SDK:

pip install daytona
npm install @daytona/sdk
gem install daytona
go get github.com/daytonaio/daytona/libs/sdk-go

En Linux, la documentación actual instala la CLI amd64 en /usr/local/bin así; el comando sobrescribe una CLI existente:

sudo curl -fL https://github.com/daytona/clients/releases/latest/download/daytona-linux-amd64 -o /usr/local/bin/daytona && sudo chmod +x /usr/local/bin/daytona
daytona login
daytona create

daytona login abre la autenticación en el navegador y guarda el token en config.json dentro del perfil activo. En Linux, el directorio predeterminado es ~/.config/daytona; DAYTONA_CONFIG_DIR permite cambiarlo. También se puede crear una clave API desde el panel y suministrarla al SDK.

Flujos de trabajo habituales

Ejecutar una comprobación aislada desde Python:

from daytona import Daytona, DaytonaConfig
config = DaytonaConfig(api_key="YOUR_API_KEY")
daytona = Daytona(config)
sandbox = daytona.create()
response = sandbox.process.code_run('print("Hello World!")')
print(response.result)

Hacer lo mismo desde TypeScript:

import { Daytona } from "@daytona/sdk";
const daytona = new Daytona({ apiKey: "YOUR_API_KEY" });
const sandbox = await daytona.create();
const response = await sandbox.process.codeRun('print("Hello World!")');
console.log(response.result);

Crear un sandbox desde una integración HTTP: enviar POST a https://app.daytona.io/api/sandbox con las cabeceras Authorization: Bearer YOUR_API_KEY y Content-Type: application/json, y un cuerpo {}. La respuesta representa el sandbox recién creado.
Restringir una sesión de CLI: al crearla, usar --target eu o --target us, --network-block-all o --network-allow-list, y --volume VOLUME_ID_OR_NAME:MOUNT_PATH cuando sea necesario controlar región, salida de red o almacenamiento montado.

Configuración esencial

DAYTONA_API_KEY: clave requerida para la autenticación de API.
DAYTONA_API_URL: URL de API; el valor documentado por defecto es https://app.daytona.io/api.
DAYTONA_TARGET: región de destino, us o eu.
DAYTONA_CONFIG_DIR: cambia el directorio de configuración de la CLI, que por defecto es ~/.config/daytona en Linux.
Archivo .env: tercer nivel de prioridad, después de parámetros explícitos y variables de entorno; útil para no codificar una clave en el programa.

Trampas frecuentes y soluciones

Instalador privilegiado y descarga a Bash: usuarios de HN criticaron el antiguo patrón de instalación con sudo y descarga canalizada. La documentación actual mostrada arriba descarga el binario explícitamente, pero aun así escribe en /usr/local/bin; revisar el binario y usar un directorio no privilegiado si la política local lo exige.
El repositorio ya no se actualiza: no construir una integración nueva suponiendo que v0.190.0 recibirá correcciones. Usar la documentación y clientes actuales de daytona, y validar compatibilidad con la versión de API en uso.
Autoeliminación inesperada: --auto-delete 0 elimina inmediatamente tras la parada. Para desactivarla, usar un valor negativo; --auto-stop 0 desactiva la parada automática.
Clonación Git con CA privada: desde v0.185.0 la clonación valida TLS por defecto. Para un host con certificado autofirmado, la vía documentada es insecure_skip_tls=true en la petición; usarla solo tras evaluar el riesgo.
Autenticación JWT: las peticiones con JWT necesitan X-Daytona-Organization-ID y el JWT tiene vida corta. Para casos simples, usar una clave API o daytona login.

Integraciones y migración

Las integraciones oficiales recuperadas conectan Daytona con Google ADK, LangChain de análisis de datos, n8n, OpenCode y Pi. La organización mantiene además clientes y MCP en daytona/clients. En el registro npm, @langchain/daytona y @mastra/daytona son adaptadores publicados por LangChain y Mastra, respectivamente.

Para migrar desde el JavaScript histórico, la última línea pública ya deprecó @daytonaio/sdk; instalar @daytona/sdk. Para claves que publican snapshots o imágenes declarativas desde contexto local, v0.187.0 exige el alcance write:snapshots o write:sandboxes. Las personas que importaban enumeraciones del cliente Python generado deben revisar los cambios de v0.184.0; la nota de versión dice que los usuarios de SDK no se ven afectados.

Cómo lo recibió la comunidad

La recepción recuperada combina interés por la experiencia de desarrollo con objeciones de seguridad y documentación:

En Hacker News 39616709, la presentación abierta de marzo de 2024 obtuvo 73 puntos y 24 comentarios. rogvodarge valoró la idea, pero pidió que la documentación explicara mejor la diferencia respecto de Nix, archivos de configuración y Ansible, además de demostraciones. 20after4 compartió que el README no dejaba suficientemente claro cómo se creaba el entorno. bitwize consideró la experiencia más sencilla que DevPod, aunque objetó el instalador con sudo y una descarga canalizada a Bash, y posteriormente describió fallos de SSH y terminal de pantalla completa. El colaborador metcalfc reconoció la crítica al instalador y enlazó una solicitud de cambios de seguimiento.
En Hacker News 48509317, sobre el paso a código cerrado, hubo 7 puntos y 3 comentarios. kgwxd dijo que el anuncio era una razón para no utilizarlo; hnthrow10282910 sostuvo que la seguridad mediante oscuridad no es la respuesta. Son objeciones de esos usuarios, no una auditoría independiente de la seguridad de Daytona.
The New Stack calificó el espacio como competitivo y cuestionó si un nuevo acrónimo para el entorno de desarrollo ayudaba a entender el producto. TechCrunch lo encuadró como alternativa empresarial a Codespaces. La reseña de Pixeljets de julio de 2025 recomendó Daytona para una plataforma completa con soporte de equipo, y prefirió Microsandbox cuando la prioridad era el aislamiento máximo; es una valoración editorial fechada antes del cambio de código de 2026.

Imagen dividida en dos: a la izquierda una senda de neón brillante con gráficos ascendentes que representan el entusiasmo del lanzamiento inicial; a la derecha una escena más oscura con señales de advertencia rojas y candados que representan el escepticismo ante el paso a código cerrado.

No se obtuvieron publicaciones verificables de Reddit: las búsquedas devolvieron el desafío de JavaScript de Reddit. X exigió autenticación, y Product Hunt devolvió un desafío de Cloudflare, por lo que no se atribuyen votos, comentarios ni consenso a esas plataformas. Un anuncio oficial de Ivan Burazin aparece enlazado desde HN 39618079, con 9 puntos y 0 comentarios en HN; eso acredita difusión, no recepción en X.

Daytona frente a otras propuestas

Propuesta	Coincidencia verificable	Diferencia verificable
GitHub Codespaces	Ambas fuentes de prensa lo sitúan como referencia de entornos de desarrollo remotos.	La fuente de The New Stack describe el planteamiento inicial de Daytona como autogestionado y apto para cortafuegos propios; no se infiere aquí una comparación de rendimiento.
E2B	Su documentación oficial ofrece ciclo de vida de sandbox, terminal, Git, snapshots, persistencia, SDK y casos para agentes de IA.	Son plataformas distintas; las fuentes recuperadas no aportan un benchmark común.
Vercel Sandbox	Documenta ejecución aislada de código no confiable o generado por IA, SDK, CLI, snapshots y persistencia.	Vercel documenta aislamiento mediante microVM Firecracker; no se afirma que el modelo de Daytona sea equivalente.
Cloudflare Sandbox SDK	Se dirige a ejecución aislada, procesos, archivos y servicios para agentes.	La comparación se limita a la categoría funcional; no se recuperó una prueba independiente de coste, latencia o seguridad.
Modal Sandboxes	Crea contenedores en tiempo de ejecución para código arbitrario, no confiable o generado por modelos.	La documentación oficial de Modal habla de contenedores; no permite establecer una superioridad sobre Daytona.

Casos de uso y a quién puede ayudar este repositorio

Equipos que construyen agentes que escriben o prueban código pueden crear un sandbox por tarea y ejecutar el resultado con los SDK, en lugar de hacerlo directamente en el proceso del agente.
Desarrolladores de flujos de automatización pueden conectar sandboxes con Google ADK, LangChain, n8n, OpenCode o Pi, según las integraciones oficiales recuperadas.
Plataformas internas con requisitos de control operativo pueden aplicar región, límites de red, montajes de volumen y políticas de parada o eliminación mediante CLI y configuración.
Mantenedores de una bifurcación del código abierto histórico disponen de una guía concreta para rebase, DCO, pruebas, generación de documentación CLI y generación de clientes. No deben asumir que esas solicitudes serán aceptadas en el producto central privado.

Recursos

Repositorio histórico: https://github.com/daytonaio/daytona
Documentación actual: https://www.daytona.io/docs/
SDK, CLI y MCP oficiales: https://github.com/daytona/clients
Integraciones oficiales: https://github.com/daytona/integrations
Guía de API y claves: https://www.daytona.io/docs/api-keys
CLI y referencia: https://www.daytona.io/docs/tools/cli
Publicaciones: https://github.com/daytonaio/daytona/releases
Conversaciones: https://news.ycombinator.com/item?id=39616709, https://news.ycombinator.com/item?id=48509317
Reseñas: https://thenewstack.io/codeanywhere-founders-take-on-github-codespaces-with-daytona/, https://techcrunch.com/2023/11/06/daytona-wants-to-be-an-enterprise-grade-github-codespaces/, https://pixeljets.com/blog/ai-sandboxes-daytona-vs-microsandbox/
Vídeos: https://www.youtube.com/watch?v=RNf_vfgc91c, https://www.youtube.com/watch?v=06aAGmZc4yI, https://www.youtube.com/watch?v=Ix2X-sjVXjw
Registro npm: https://www.npmjs.com/package/@daytona/sdk
Registro PyPI: https://pypi.org/project/daytona/

Nota: este artículo combina el README y las guías de Daytona, las notas de publicación, la API de GitHub, documentación de integraciones y fuentes de comunidad consultadas el 8 de agosto de 2026. Las cifras cambian con el tiempo.