Daytona: Agent Sandboxes, Not a CDE
Daytona left the development environment category for AI agent sandboxes. It keeps appearing on CDE shortlists because comparison articles have not caught up, and evaluating it as a Codespaces alternative wastes everyone's time.
What It Is
Sandbox infrastructure for running AI-generated code, not a place for developers to work
Do not evaluate Daytona as a cloud development environment. If you arrived from an article listing it as a self-hosted Codespaces alternative, that article is describing a product that no longer exists in that form. Daytona's homepage headline is "Run AI Code", with the subheadline "Secure and Elastic Infrastructure for Running Your AI-Generated Code". Nothing in its current product positioning is about provisioning workspaces for human developers.
Daytona today sells stateful sandboxes that agents create, use, snapshot, fork, and discard programmatically. A mid-page section on its site describes the offering as "AI-First Infrastructure. Optimized for LLMs, Agents, and Evals", and other headings frame it as the runtime that AI agents actually need rather than as a sandbox alone. The product surface is an SDK and an API, and the consumer is a program.
That is a real and defensible business. Running model-generated code that no human reviewed is a genuine infrastructure problem with genuine demand, and Daytona is one of the more visible companies solving it. This page is not a criticism of the pivot. It exists because the old positioning is still cached across the internet, and because a team that shortlists Daytona for developer workspaces will spend a week discovering that.
One nuance, in fairness. The homepage is not entirely free of development-environment language: customer testimonials still reference the pain of provisioning development environments, and a "Human in the Loop" section offers SSH access, a browser VS Code, and a web terminal. Those are debugging affordances on an agent sandbox, not a workspace product, and it would be wrong to read them as a remaining CDE. But they are why the confusion persists.
Programmatic, not interactive
Sandboxes are created and destroyed by code through an SDK. There is no notion of a developer being assigned a long-lived workspace.
Stateful, with fork and resume
Snapshotting and forking sandbox state is the differentiating capability, aimed at branching agent trajectories and evaluation runs.
Computer Use desktops
Documented as programmatic control of desktop environments inside sandboxes - mouse, keyboard, screenshot, and screen recording operations - built on Xvfb, xfce4, x11vnc, and noVNC.
Who It Suits, and Who It Does Not
An unusually clean split, because the product changed categories rather than tiers
A good fit
- Teams building products that execute model-generated code, where isolation is a hard requirement rather than a preference.
- Agent evaluation harnesses, where forking sandbox state to branch trajectories is a first-class need.
- Workloads needing a controllable graphical desktop for an agent, which is a genuinely uncommon capability.
- Agent workloads that specifically need Windows, since Windows sandboxes are offered with a published rate.
- Teams wanting to start on a credit balance rather than a contract, and larger accounts wanting compute in their own infrastructure.
A poor fit
- Anyone looking for a cloud development environment for people. This is the main reason readers arrive here, and the answer is no.
- Teams that wanted the earlier self-hosted, open-source Daytona. Core development moved to a private codebase and the public repository is explicitly unmaintained.
- Buyers who need a full published rate card before starting. Only some rates are publicly retrievable.
- Organizations that require a long operating history from infrastructure vendors. This is a Series A company in a young category.
- Teams whose agent work fits comfortably inside an existing CDE or CI runner, where a second vendor adds cost without adding safety.
If you came here from a comparison table
Go back and check the date on it. A comparison article that still lists Daytona alongside Coder, Gitpod, and Codespaces as an open-source self-hosted CDE is old enough that its other entries are probably wrong too - Gitpod has been renamed and has an acquisition pending, and two AWS products in the same tables are closed to new customers. Treat a stale Daytona entry as a signal about the whole document. The tools comparison and the market guide track the current state.
Deployment Model
A hosted API by default, with customer-provided compute as an option
| Concern | Hosted (default) | Bring your own compute |
|---|---|---|
| Control plane | Daytona | Daytona. The custom region is compute, not a control plane you run. |
| Where code executes | Daytona's infrastructure | Compute your organization provides and manages, as a custom region |
| You integrate with | SDK and API from your own application | The same SDK and API |
| Availability | Any account, gated by usage tier | Listed as an Enterprise capability on the pricing page; the documentation describes it as a general feature without naming a plan restriction |
Bring-your-own-compute is worth understanding precisely, because the phrase gets used to mean self-hosting and it does not mean that here. Daytona's documentation describes custom regions as compute your organization provides and manages. That satisfies a data-locality requirement. It does not give you a system you could keep operating without Daytona, and it is not a return to the self-hostable product that earlier articles describe.
Capacity is also tier-gated rather than open-ended. Published limits step up with account verification and prepaid balance, from a first tier of 10 vCPU, 20 GiB RAM, and 30 GiB storage through progressively larger tiers to an Enterprise arrangement. Anyone planning a high-concurrency evaluation harness should check those ceilings before designing around them: daytona.io/docs.
License and Open Source Reality
AGPL-3.0 on the tags, still public, and explicitly no longer maintained
Daytona announced in June 2026 that it was going closed source. The commercial product is proprietary. What remains public is the historical repository, and the details matter because this case is often reported inaccurately in both directions.
Not archived
The daytonaio/daytona repository is still public and not archived. Descriptions calling it archived are wrong.
AGPL-3.0, but on the tags
This is the single most misread fact about this repository, so read it precisely. The license was not swapped for a restrictive one on the way out, but it is not on the default branch either. That branch carries no license file and the GitHub API detects no license for the repository at all, because the source code is no longer there - its root now holds only a README and an assets directory. AGPL-3.0 lives on the tagged releases, and v0.190.0 still carries it. The README's own license link points at the v0.190.0 tag rather than at the branch, which is exactly why a quick check wrongly suggests the whole repository is AGPL-3.0. Anyone depending on this code must pin a tag and read that tag's license.
Explicitly unmaintained
The repository carries a notice that it is no longer maintained, that core development moved to a private codebase as of June 2026, and that it will receive no further updates, fixes, or releases.
Give credit where it is due, then plan accordingly
This is a comparatively honest way to close a project. Daytona's own post says the open source repository is not going anywhere, that it will stay public so anyone who wants to keep using it, fork it, or build on it can continue to do so, and that it will no longer be maintained or updated but remains available as is. That is clearer than a silent stall, and clearer than a relicensing.
It also does not make the code a viable foundation. Unmaintained infrastructure software accumulates unpatched dependencies immediately, and adopting it means becoming its maintainer for a platform of substantial size. Read that notice as an accurate description of what you would be taking on: github.com/daytonaio/daytona. See also open source CDEs, which uses this case as a worked example.
Pricing
Usage-based, partially published, and worth verifying signed in
| Item | As of July 2026 |
|---|---|
| Free compute on signup | $200 in credits |
| Model | Pay as you go on resources reserved for your sandboxes - vCPU, RAM, and disk - with volume discounts |
| Windows sandboxes | $0.0858 per vCPU-hour |
| Linux vCPU, RAM, and disk rates | Not publicly retrievable. The Linux rate table renders client-side and does not appear in the documentation. No figure is quoted here rather than guessing. |
| Storage | Priced per GiB after the first 5 GiB free |
| Enterprise | Custom, adding larger limits, single sign-on, audit logs, and bring-your-own-compute |
| Startup program | Up to $50,000 in credits |
All figures above are from Daytona's own pricing page as of July 2026: daytona.io/pricing. Where a rate could not be retrieved from the published page, this table says so instead of substituting an aggregator's number.
What to model, since a per-hour rate is the wrong mental model
Agent sandbox spend is driven by invocation volume and sandbox lifetime, not by headcount. A hundred developers with an eight-hour day is a predictable curve. An agent loop that opens a sandbox per task can produce ten thousand short-lived sandboxes on a busy afternoon and almost none overnight, and the cost driver becomes how aggressively your code destroys them.
Instrument sandbox count and lifetime before scaling, set hard ceilings in your own code rather than relying on the tier limits as a safety net, and re-check rates signed in. FinOps for development environments and agent fleets cover the control patterns.
Architecture and Isolation
Fast, stateful sandboxes, with the performance numbers attributed to the vendor
These are vendor claims, not independent measurements. Daytona states that sandboxes spin up in under 90 ms from code to execution, and this site has not benchmarked that. Note how the claim is scoped, because Daytona is not consistent about it: the homepage and the documentation landing page both state it flat, as a property of the platform, with no runtime named. The runtime comparison in the getting-started documentation attaches the same figure to the default Linux container runtime and does not attach it to the Windows VM runtime, which is documented separately and priced separately. Read the headline form as unscoped, and do not assume it covers a Windows sandbox. Benchmark against your own workload, runtime, and region before designing a latency budget around it.
Statefulness is the differentiator
Snapshot, fork, and resume let an agent branch from a known state rather than rebuilding it. For evaluation runs that need many variants of one starting point, that is a substantial saving.
Desktop control
The Computer Use documentation describes mouse, keyboard, screenshot, screen recording, and display operations within a sandbox, with Linux, macOS, and Windows desktop options listed on the site.
Ask about the boundary
If you are running genuinely hostile code, get the isolation mechanism in writing rather than inferring it from marketing language. "Secure sandbox" is a claim, not an architecture.
That last point is the one to press hardest in a technical evaluation. Sandbox vendors differ substantially in what separates one tenant's code from another's - hardware virtualization, kernel-level sandboxing, or ordinary containers with a strong name - and the difference determines whether a container escape is a bug or a breach. E2B states Firecracker microVMs explicitly, which is a useful benchmark for the specificity to demand. See microVM isolation, sandbox environments, and Kubernetes agent sandboxes.
Status and Durability
Funded and active, having already changed direction once
Daytona raised a $24M Series A led by FirstMark Capital, announced on 02-05-2026, with Datadog and Figma Ventures participating as strategic investors alongside Pace Capital, Upfront Ventures, Darkmode, E2VC, and a group of angels. That is a well-supported position in a category attracting real investment, and it means the company has runway to keep building.
It is also a company that has already exited one market, and it said so plainly. Daytona announced the repositioning on 04-17-2025 in From Dev Environments to AI Runtimes, where CEO Ivan Burazin wrote that "Daytona has decided to realign its focus from solving developer environment inconsistencies for humans to solving runtimes for AI agents." That post dates the internal inflection to December 2024. The theme is traceable further back still, to posts on agent-agnostic sandbox infrastructure from October 2024, though Daytona was still describing itself as a CDE as late as 12-30-2024, so October marks the earliest trace of the idea rather than a completed pivot. The closed-source announcement followed on 06-11-2026.
What the history actually tells you
Not that the company is unreliable - repositioning toward a better market is what a startup is supposed to do, and doing it early was arguably good judgment. What it tells you is that the product category is a choice this company has shown it will revisit. Customers of the previous product did not get a migration path; they got a different company.
How to buy it anyway
Keep the integration behind an interface of your own so a sandbox provider is swappable, since the create-run-snapshot-destroy shape is broadly similar across vendors. Avoid making proprietary snapshot semantics load-bearing. That is ordinary prudence for a Series A dependency, not a specific accusation.
A closing observation about this category rather than this company. Every stale comparison table that still lists Daytona as an open-source self-hosted CDE is quietly teaching readers something false, and those tables outnumber the corrections. The general lesson is to verify a vendor's current positioning from its own homepage before shortlisting it, because the market moved faster than the writing about it. Vendor evaluation builds that check into a process.
Related
Actual CDEs if that is what you wanted, and the agent sandbox context if it is not
E2B vs Daytona
The other agent sandbox vendor, on isolation, state, and how each one got here
Self-Hosted vs Managed
The framework for the CDE choice this product left
E2B
The most direct competitor, with an explicit Firecracker microVM isolation story and an open source, self-hostable stack
GitHub Codespaces
If you actually wanted a development environment, start here rather than with an agent sandbox
Open Source CDEs
Where to look if what attracted you was the old self-hosted, open-source Daytona
Sandbox Environments
The category Daytona now competes in, and how to evaluate it on its own terms
MicroVM Isolation
What separation guarantee to demand before running unreviewed code, and how to ask for it
Agent Fleets
Running many agents concurrently, and the cost and concurrency ceilings that shape it
All CDE Tools
The current state of the category, with the discontinued and repositioned entries marked
CDE Market Guide
Who left the category, who entered it, and why the shortlists went stale so quickly
Sources and Citations
Every figure on this site with its publisher, date, and link