AI Potluck
Infrastructure / Deployment

Daytona Sandbox

Daytona

Daytona provisions stateful sandboxes for running AI-generated code, putting sandbox creation, execution and deletion under programmatic control through SDKs for Python, TypeScript, Ruby, Go and Java. The same API exposes process execution with streamed output, file system operations, Git and a built-in language server. Daytona sells it as a hosted cloud aimed at coding agents, code interpreters and agent evaluation across parallel snapshot states.

The public repository is no longer maintained - core development moved to a private codebase in June 2026 - so the openness axis reads a frozen snapshot rather than what currently ships. Verified 2026-08-13 via daytona.io and the ComputeSDK sandbox benchmark leaderboard.

Openness

4 high confidence
4.0
license
AGPL-3.0(OSI, copyleft)
source
public
managed-tier
app.daytona.io hosted cloud + hybrid (proprietary)
core-gated
gated(core development moved to a private codebase in June 2026 - daytonaio/daytona now holds only a README and logos, and the daytona org publishes SDKs and clients but no server or runtime)

AGPL-3.0 with public source and a gated core - a combination that describes Daytona as it stood at v0.190.0 rather than as it ships now. The upstream repo carries a notice that "as of June 2026, Daytona’s core development has moved to a private codebase", and its default branch is down to a README and two logo files with no source and no LICENSE. The daytona org publishes SDKs, clients and legacy provider plugins only - no server and no sandbox runtime. The core is therefore gated on the strongest possible reading: the whole current product is withheld from the published source, which is a frozen and abandoned snapshot. That also puts the public-source reading in doubt - judged on the current release this is closer to partial source, which would place the product below open core - and the tension between what the repository now shows and where this record sits is stated here rather than resolved.

  • https://github.com/daytonaio/daytona recorded 2026-06-04

    AGPL-3.0 license; secure runtime for AI-generated code; managed cloud at app.daytona.io

  • https://api.github.com/repos/daytonaio/daytona/git/trees/main?recursive=1 recorded 2026-08-12

    Full untruncated recursive tree of the default branch: 5 entries in total - README.md, assets/, assets/images/ and two logo PNGs. No source, no LICENSE file. The repo is not archived and was last pushed 2026-07-24.

  • https://raw.githubusercontent.com/daytonaio/daytona/main/README.md recorded 2026-08-12

    "This repository is no longer maintained. As of June 2026, Daytona’s core development has moved to a private codebase. This repository will receive no further updates, fixes, or releases. It remains public and free to use, fork, and build on under the LICENSE (linked at tag v0.190.0), as is and without support or warranty."

  • https://api.github.com/orgs/daytona/repos?per_page=100 recorded 2026-08-12

    The org the README redirects to publishes SDKs and clients (daytona/sdk, daytona/clients - "Official SDKs, API clients, and CLI/MCP tools"), legacy provider plugins and samples. No server, control plane or sandbox runtime repository.

  • https://raw.githubusercontent.com/daytonaio/daytona/v0.190.0/LICENSE recorded 2026-08-12

    The GNU Affero General Public License v3, verbatim. This is the tag the unmaintained README points at, and it is the only place the AGPL-3.0 grant now lives - the default branch carries no LICENSE file at all, and GitHub's repo metadata reports a null license for daytonaio/daytona as a result. So the recorded AGPL-3.0 is a fact about v0.190.0, not about anything Daytona currently ships.

Adoption

5 medium confidence
5.0

PyPI reports 10,225,169 downloads in the trailing month for the daytona package, which crosses the 10M floor and bands at level 5. Part of that volume is inherited from the prior dev-environment product line, but the package now ships the sandbox SDK. This is a near-boundary crossing and is recorded as one: the figure clears the floor by 2.25%, a month of ordinary variance would put it back at level 4, and the trailing-month window moves daily, so confidence is medium rather than high. The package is the product’s own - its PyPI metadata gives the author as Daytona Platforms Inc. at support@daytona.io and the summary as "Python SDK for Daytona" - so this is not a same-name match.

  • https://pypistats.org/packages/daytona recorded 2026-06-04

    ~8,313,410 downloads last month

  • https://pypistats.org/api/packages/daytona/recent recorded 2026-08-14

    recent_downloads for package daytona - last_month 10,225,169, last_week 2,311,963, last_day 423,576. The trailing-month figure is the one the software adoption scale bands on.

  • https://pypi.org/pypi/daytona/json recorded 2026-08-14

    Package metadata - name daytona, summary "Python SDK for Daytona", author "Daytona Platforms Inc.", author_email support@daytona.io, license Apache-2.0, version 0.204.0. Confirms the banded package is the product's own SDK.

Capability

4 high confidence
4.0

Strong isolation - a dedicated kernel with its own filesystem and network stack, and allocated vCPU, RAM and disk - with sub-90ms cold-start and persistent sessions; among the strongest agent-runtime feature sets, just below the kernel and microVM frontier-definers. Independent ComputeSDK TTI benchmarks corroborate the sub-100ms-class cold-start at a ~140ms median, 4th-fastest of 19 sandbox providers. The cited GitHub repo is a stub, but Daytona’s docs carry the isolation claim almost word for word - "Each sandbox runs in isolation, giving it a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM, and disk" - and the docs index gives "spinning up in under 90ms from code to execution". Two limits scope that claim. Sandboxes run as Linux containers by default and the sub-90ms figure attaches to that container class, with Linux VM and Windows VM as separate opt-in runtimes, so reading the whole product as VM-class overstates it. And persistent state across sessions is scoped to the VM class, which is what carries fork, pause/resume and memory snapshots; GPU sandboxes are explicitly ephemeral. The docs name no isolation technology - no gVisor, no Firecracker - only OCI and Docker compatibility, so no microVM mechanism is asserted. The feature set behind the 4 stands on that narrower scoping.

  • https://daytona.io/docs/en/sandboxes recorded 2026-08-14

    "Daytona provides full composable computers - sandboxes - for AI agents. Sandboxes are isolated runtime environments you can manage programmatically to run code."; "Each sandbox runs in isolation, giving it a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM, and disk."; "Sandboxes run as Linux containers by default. Daytona also provides VM sandboxes with a dedicated Linux VM or Windows operating system, and GPU sandboxes"; runtime comparison table rows Container (default, <90ms, dynamic builds, Docker images), Linux VM and Windows; "GPU sandboxes are ephemeral"; fork, pause/resume and snapshot-from-sandbox are documented sandbox operations

  • https://daytona.io/docs/ recorded 2026-08-14

    docs index - "Sandboxes - for AI agents with complete isolation, a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM, and disk", "spinning up in under 90ms from code to execution and running any code in Python, TypeScript, and JavaScript. Built on OCI/Docker" compatibility

  • https://github.com/daytonaio/daytona recorded 2026-06-04

    The repo behind the isolation and spin-up claims is a README stub carrying neither, which is why the docs are cited for them instead.

  • https://www.computesdk.com/benchmarks/sandboxes/ recorded 2026-07-09

    ComputeSDK TTI leaderboard (independent, 100 iters/day, 2026-07-09 run): median time-to-interactive ~140ms sequential / ~710ms burst @100 concurrent; 4th-fastest of 19 providers

Verified 2026-08-12