Daytona: from open dev-environment manager to a sandbox platform for agents

Everything worth knowing about daytonaio/daytona: the historical repository of a platform that creates isolated environments for running AI-generated code, and which, since June 2026, no longer receives public development.

---

What Daytona is

Daytona provides elastic, isolated infrastructure for running code, in particular code generated by AI agents. The daytonaio/daytona repository holds the historical public implementation, and its README ships clients, an API, a CLI, and examples for creating a sandbox, running a process, and collecting the result.

The proposition evolved. At its 2024 public launch it was presented as a development-environment manager; the current documentation describes sandboxes as isolated computers for agent workloads, with Linux containers by default and additional machine classes for Linux, Windows, and NVIDIA GPU virtual machines. That does not mean every backend offers the same capabilities or availability.

There is a decisive warning: the current README states that, since June 2026, core development moved to a private codebase. The repository remains usable and forkable under its license, but with no new fixes, releases, or support. This dispatch therefore distinguishes between the historical daytonaio/daytona code and the current daytona API, docs, and clients.

The origin: from Codeanywhere to an enterprise alternative to Codespaces

The New Stack’s September 6, 2023 coverage attributes Daytona to Codeanywhere’s founders and describes the attempt to offer self-hosted development environments, including behind a firewall, as an answer to GitHub Codespaces. TechCrunch reported on November 6, 2023 on a $2 million pre-seed round and summarized the positioning as an enterprise-grade alternative to Codespaces.

The public repository was created on February 6, 2024. On March 6, 2024, the team introduced the open launch on Hacker News as the result of a fifteen-year journey. The original tension was practical: making development environments reproducible and remote without depending solely on a vendor-hosted development service. Over time, the documented emphasis shifted toward isolating agent code execution.

The 2026 move to a private core codebase produced the opposite tension. The team stated in the README that the decision responded to vulnerabilities discovered through static and AI-driven analysis, but public debate questioned whether hiding the code is an adequate response to security.

Philosophy and principles

The documentation and retrieved sources support these principles:

• Isolation before direct execution: an agent or application creates a sandbox instead of running untrusted code inside its own process or machine.
• Ephemeral, programmable environments: an SDK, a REST API, and a CLI allow creating, using, pausing, stopping, or deleting instances through code.
• Integration, not its own agent: Daytona supplies the compute environment and connects to agent frameworks; it does not aim to replace them.
• Separation between control plane and workloads: keys, regions, network limits, and lifecycles are configured explicitly.

This is an analysis of the documented interfaces, not a security certification. The isolation guarantee depends on the sandbox type and the selected configuration.

How it works

The minimal API flow is to create an authenticated client, request a sandbox, and run code inside it. For example, the README shows daytona.create() and sandbox.process.code_run(...) in Python; in TypeScript it uses await daytona.create() and sandbox.process.codeRun(...). The equivalent REST API creates a sandbox with POST https://app.daytona.io/api/sandbox and a Bearer header.

The CLI offers interactive, scriptable access. daytona create starts creation, while the current reference documents lifecycle controls such as --auto-stop, --auto-delete, --auto-archive, --target, volumes, and network policies. Values matter: --auto-stop 0 disables automatic stopping; --auto-delete 0 deletes the sandbox as soon as it stops; and a negative --auto-delete value disables automatic deletion.

Configuration resolves in this order: explicit parameters in code, environment variables, a .env file, and defaults. Early variables include DAYTONA_API_KEY, DAYTONA_API_URL, DAYTONA_TARGET, DAYTONA_ORGANIZATION_ID, and DAYTONA_JWT_TOKEN.

Official and semi-official status

The repository studied here was an official Daytona project, but it is no longer the maintained public core: its own README announces the move to private code. No public Daytona marketplace was found at the tested official URL; https://www.daytona.io/marketplace returns a moved-or-missing resource page.

There is verifiable official or semi-official integration in the limited sense of packages and repositories published by the organization: daytona/clients gathers the SDK, CLI, and MCP; daytona/integrations contains packages for Google ADK, LangChain data-analysis, n8n, OpenCode, and Pi. On npm, @daytona/sdk, @daytona/opencode, @daytona/pi, and @daytona/n8n-nodes-daytona are attributed to Daytona Platforms Inc. LangChain publishes @langchain/daytona and Mastra publishes @mastra/daytona; those are integrations built by those vendors, not a blanket endorsement of the platform by every vendor.

The ecosystem

Related official repositories

• daytona/clients: official clients and SDKs for TypeScript, Python, Ruby, Go, and Java; it also bundles the CLI and MCP.
• daytona/integrations: official integrations for Google ADK, LangChain data-analysis, n8n, OpenCode, and Pi.
• daytona/homebrew-tap: the official Homebrew formula.
• daytona/guides: runnable sandbox examples.
• The historical daytonaio organization also maintains, among other things, Helm charts, Terraform modules, a CLI Homebrew formula, and a network allowlist; several older samples and plugins are archived.

Star counts for these repositories are not included because their individual metrics were not retrieved in this run. The relationship itself is verified by the organizations’ listings and the linked repositories.

Forks, extensions, and packages

The GitHub API records 5,658 forks of daytonaio/daytona as of August 8, 2026. Among the most visible ones returned by the endpoint were copies such as gauravsonii/daytona, Supriya0446/daytona, and jamesmurdza/daytona; no documentation was retrieved showing they are independent ports, so they are classified only as forks.

The confirmed extension surface is the official daytona/integrations repository and the cited npm packages. No non-English translation or community port with an explicit relationship was retrieved that would justify presenting it as an extension of the project.

Repo numbers

Measurement: August 8, 2026, GitHub API for daytonaio/daytona.

Metric	Value
Stars	72,024
Forks	5,658
Real subscribers	122
Commits	2,744
Open issues reported by the API	440
Created	February 6, 2024
Last recorded push	July 24, 2026
Metadata refresh	August 8, 2026
Latest public release	v0.190.0, June 23, 2026

The leading contributors returned by the API, by contributions, were Tpuljak (661), idagelic (439), MDzaja (170), fabjanvucina (167), and stefanicjuraj (138). The 2,744-commit total comes from the last page of the API’s commit pagination link. The response did not surface a primary language or license in those fields, so they are omitted rather than inferred. open_issues_count can include open pull requests, so it is not an issues-only count. Also, watchers_count mirrors star counts in GitHub’s general API response; subscribers_count is reported here as the real subscriber figure.

How to contribute

The retrievable contribution guide corresponds to the final public tag v0.190.0, so it applies to forks or the archived code, not as a promise of acceptance into the current product:

1. For core work, discuss it on Slack first and create or find an associated issue.
2. Fork the repo, keep each pull request focused on a single change, and rebase against main with git rebase.
3. Add functional or integration tests and documentation.
4. Squash the work into a descriptive commit and sign it off with DCO: git commit --signoff --message "This is the commit message".
5. For CLI commands, run ./hack/generate-cli-docs.sh; for API spec changes, ./hack/swagger.sh.
6. Use Yarn for Node dependencies and run golangci-lint run.

The historical guide accepted draft pull requests and stated that merges into main would trigger a release. The current notice of no future releases invalidates that expectation for the original repository.

Quick-start guide

Installation and first run

For a new integration, the historical README documents the SDKs:

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

On Linux, the current documentation installs the amd64 CLI into /usr/local/bin like this; the command overwrites an existing CLI:

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 opens browser authentication and stores the token in config.json inside the active profile. On Linux, the default directory is ~/.config/daytona; DAYTONA_CONFIG_DIR lets you change it. An API key can also be created from the dashboard and supplied to the SDK.

Common workflows

1. Run an isolated check from 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)

2. Do the same from 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);

3. Create a sandbox from an HTTP integration: send a POST to https://app.daytona.io/api/sandbox with the Authorization: Bearer YOUR_API_KEY and Content-Type: application/json headers, and a {} body. The response represents the newly created sandbox.

4. Restrict a CLI session: at creation time, use --target eu or --target us, --network-block-all or --network-allow-list, and --volume VOLUME_ID_OR_NAME:MOUNT_PATH whenever you need to control region, network egress, or mounted storage.

Essential configuration

• DAYTONA_API_KEY: required key for API authentication.
• DAYTONA_API_URL: API URL; the documented default is https://app.daytona.io/api.
• DAYTONA_TARGET: target region, us or eu.
• DAYTONA_CONFIG_DIR: changes the CLI configuration directory, which defaults to ~/.config/daytona on Linux.
• .env file: third priority level, after explicit parameters and environment variables; useful for keeping a key out of the program itself.

Common pitfalls and fixes

• Privileged installer and pipe-to-Bash download: HN users criticized the older sudo-plus-piped-download install pattern. The current documentation shown above downloads the binary explicitly, but still writes to /usr/local/bin; review the binary and use an unprivileged directory if local policy requires it.
• The repository no longer gets updates: don’t build a new integration assuming v0.190.0 will receive fixes. Use the current daytona documentation and clients, and validate compatibility with the API version in use.
• Unexpected auto-deletion: --auto-delete 0 deletes the sandbox immediately after it stops. To disable it, use a negative value; --auto-stop 0 disables automatic stopping.
• Git cloning with a private CA: since v0.185.0, cloning validates TLS by default. For a host with a self-signed certificate, the documented path is insecure_skip_tls=true on the request; use it only after evaluating the risk.
• JWT authentication: requests using a JWT need X-Daytona-Organization-ID, and the JWT is short-lived. For simple cases, use an API key or daytona login.

Integrations and migration

The retrieved official integrations connect Daytona with Google ADK, LangChain data-analysis, n8n, OpenCode, and Pi. The organization also maintains clients and MCP in daytona/clients. On the npm registry, @langchain/daytona and @mastra/daytona are adapters published by LangChain and Mastra, respectively.

To migrate from the historical JavaScript, the last public line already deprecated @daytonaio/sdk; install @daytona/sdk instead. For keys that publish snapshots or declarative images from local context, v0.187.0 requires the write:snapshots or write:sandboxes scope. People who imported enums from the generated Python client should review the v0.184.0 changes; the release note says SDK users are unaffected.

How the community received it

The retrieved reception combines interest in the developer experience with objections about security and documentation:

• On Hacker News 39616709, the March 2024 open launch got 73 points and 24 comments. rogvodarge liked the idea but asked that the documentation better explain the difference from Nix, config files, and Ansible, plus provide demos. 20after4 shared that the README did not make clear enough how the environment was created. bitwize found the experience simpler than DevPod, though objected to the sudo installer and pipe-to-Bash download, and later described SSH and full-screen terminal failures. Contributor metcalfc acknowledged the installer criticism and linked a follow-up pull request.
• On Hacker News 48509317, about the move to closed code, there were 7 points and 3 comments. kgwxd said the announcement was a reason not to use it; hnthrow10282910 argued that security through obscurity is not the answer. Those are objections from those users, not an independent audit of Daytona’s security.
• The New Stack called the space competitive and questioned whether a new acronym for the development environment helped explain the product. TechCrunch framed it as an enterprise alternative to Codespaces. Pixeljets’ July 2025 review recommended Daytona for a full platform with team support, and preferred Microsandbox when maximum isolation was the priority; that is an editorial assessment dated before the 2026 code change.

No verifiable Reddit posts were obtained: the searches returned Reddit’s JavaScript challenge. X required authentication, and Product Hunt returned a Cloudflare challenge, so no votes, comments, or consensus are attributed to those platforms. An official announcement from Ivan Burazin appears linked from HN 39618079, with 9 points and 0 comments on HN; that shows distribution, not reception on X.

Daytona vs other approaches

Approach	Verifiable overlap	Verifiable difference
GitHub Codespaces	Both press sources position it as a reference point for remote development environments.	The New Stack’s source describes Daytona’s initial approach as self-hosted and firewall-friendly; no performance comparison is inferred here.
E2B	Its official documentation offers sandbox lifecycle, terminal, Git, snapshots, persistence, an SDK, and AI-agent use cases.	These are separate platforms; the retrieved sources do not provide a common benchmark.
Vercel Sandbox	Documents isolated execution of untrusted or AI-generated code, an SDK, CLI, snapshots, and persistence.	Vercel documents isolation via Firecracker microVMs; Daytona’s model is not claimed to be equivalent.
Cloudflare Sandbox SDK	Targets isolated execution, processes, files, and services for agents.	The comparison is limited to the functional category; no independent test of cost, latency, or security was retrieved.
Modal Sandboxes	Creates runtime containers for arbitrary, untrusted, or model-generated code.	Modal’s official documentation talks about containers; it does not allow establishing superiority over Daytona.

Use cases and who this repository can help

• Teams building agents that write or test code can create one sandbox per task and run the result through the SDKs, rather than executing it directly inside the agent’s own process.
• Automation-workflow developers can connect sandboxes to Google ADK, LangChain, n8n, OpenCode, or Pi, based on the retrieved official integrations.
• Internal platforms with operational control requirements can apply region, network limits, volume mounts, and stop-or-delete policies through the CLI and configuration.
• Maintainers of a fork of the historical open-source code have a concrete guide for rebasing, DCO, tests, CLI doc generation, and client generation. They should not assume those pull requests will be accepted into the private core product.

Resources

• Historical repository: https://github.com/daytonaio/daytona
• Current documentation: https://www.daytona.io/docs/
• Official SDK, CLI, and MCP: https://github.com/daytona/clients
• Official integrations: https://github.com/daytona/integrations
• API and keys guide: https://www.daytona.io/docs/api-keys
• CLI reference: https://www.daytona.io/docs/tools/cli
• Releases: https://github.com/daytonaio/daytona/releases
• Discussions: https://news.ycombinator.com/item?id=39616709, https://news.ycombinator.com/item?id=48509317
• Reviews: 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/
• Videos: https://www.youtube.com/watch?v=RNf_vfgc91c, https://www.youtube.com/watch?v=06aAGmZc4yI, https://www.youtube.com/watch?v=Ix2X-sjVXjw
• npm registry: https://www.npmjs.com/package/@daytona/sdk
• PyPI registry: https://pypi.org/project/daytona/

---

Note: this article combines Daytona’s README and guides, release notes, the GitHub API, integration documentation, and community sources consulted on August 8, 2026. Figures change over time.