Daytona kept its name and its licence tag, and gave away the code

The repository is a README and an assets folder, with no source in it

The complete file listing is two entries: `README.md` and `assets/`. There is no source directory, no package manifest, no lockfile, no container file, no licence file and no test directory. The repository metadata reports no primary language and no licence name.

So the sentence in the README saying the project remains free to use, fork and build on is describing a state that the default branch no longer has. You cannot clone this repository and build it. There is nothing to build. Anything you want to run has to come from a historical tag, or from a fork that predates June 2026, which means the commit you start from is not the commit the repository currently points at.

The `assets` directory is the residue of a working project rather than a source tree. It holds the logotype images the README references through light and dark variants, so what remains is the part of the repository that existed to render a front page.

The practical consequence for anyone who found this project through a search for sandbox infrastructure is that the repository is now a signpost rather than a product. It is honest about that in its first line, which is more than a repository that quietly stopped updating would be, but a signpost cannot be depended on, cloned, or pinned.

Core development moved to a private codebase, and v0.190.0 is the last release

The first element of the README is a callout that states the position plainly. It says the repository is no longer maintained, that as of June 2026 Daytona's core development has moved to a private codebase, and that the repository will receive no further updates, fixes or releases. It then points readers to the `github.com/daytona` organisation for Daytona resources.

The release list is consistent with that and gives the boundary a date. v0.188.0 was published on 2026-06-16, v0.189.0 on 2026-06-19, and v0.190.0 on 2026-06-23. The last push to the main branch was 2026-07-24, so the final commit came about a month after the last release, which is consistent with a repository being reduced to a signpost rather than with a fix being shipped.

So there is a hard edge, and it falls in late June 2026. Before it, releases existed. After it, none will. Anything published after v0.190.0 is not coming from here.

For a project whose purpose is running code that an agent wrote, the end of the release line is the operative fact rather than a footnote. The workload this runtime was built for is untrusted by construction, which means the value of an upstream fix cadence was unusually high for this particular product, and that value went to zero at a fixed date.

The licence link points at tag v0.190.0, because the default branch has none

The licensing sentence links to `blob/v0.190.0/LICENSE` rather than to a path on the current branch. That detail carries more information than it appears to. The licence file the project points you to lives on a specific historical tag, and the default branch of the repository does not have one of its own.

The repository metadata agrees: the licence field is empty, where a project with a detectable licence file usually resolves a name. So neither the current checkout nor the metadata tells you the terms, and the only artefact is one tag behind the tip.

For a fork, that matters more than it would for ordinary use. When you fork a repository, the terms you are relying on are the ones attached to the commit you forked, and here the commit with a readable licence is v0.190.0 rather than anything later. A fork taken from main inherits a tree with no licence file and no source, which is a worse starting point than a fork taken from the tag, and the difference is invisible unless you notice which ref the README links to.

The other half of the sentence is the warranty position. The README says the project is available as is, and without support or warranty. Nothing in the README qualifies that, so for this project the absence of a support commitment is a stated term rather than an inference.

Three releases in eight days, on a line that had reached 0.190.0

Look at the three remaining releases as a sequence rather than a list. v0.188.0 on 2026-06-16, v0.189.0 on 2026-06-19, v0.190.0 on 2026-06-23. That is three releases in eight days, and then the release line stops.

The version numbers tell you something the dates do not. This was the one hundred and ninetieth release of a 0.x line, which is a long history of iteration on a project that never reached a 1.0. A high number in a 0.x line is easy to misread as maturity, and here it is closer to the opposite: it marks a project that kept reshaping its interface for a long time and was still calling it 0.x when development moved behind a private codebase.

So the release history offers two contradictory signals and no way to resolve them from the repository. The commit volume suggests a busy project. The fact that it was still pre-1.0 after one hundred and ninety releases suggests an interface that had not settled. And the abandonment of the open repository is consistent with a team concluding that the shape of the product was going to change more than the open line could absorb.

For someone deciding whether to base work on the frozen tag, the lesson is that the version number tells you nothing about API stability here. Read the tag's own notes, not its number.

The feature matrix is a hosted platform's surface, and only part of it is the runtime

The README organises the product into five columns, and reading them together shows what kind of thing this was. Platform covers Organizations, API Keys, Limits, Billing, Audit logs, OpenTelemetry and Integrations. Sandboxes covers Environment, Snapshots, a Declarative builder, Volumes and Regions. Agent tools covers process and code execution, file system operations, the language server protocol, computer use, an MCP server, git operations, a pseudo terminal and log streaming. Human tools covers a dashboard, a web terminal, SSH, VNC, VPN connection, a preview and a playground. System tools covers webhooks and network limits.

The runtime a self-hoster would actually want is the second column. Billing, regions, VPN connections and a dashboard only mean something as parts of a service someone else operates, and a preview proxy and a playground are user-interface features of a hosted product.

That is the central difficulty for anyone who liked the design and wanted to run it. The valuable component, the sandbox, was published alongside a platform layer that assumed a commercial operator, and the two are described in one matrix with no separation between them. Self-hosting the runtime meant either reimplementing the platform layer or accepting a reduced feature set, and the README does not say which features degrade without billing, regions or the VPN.

The agent-facing surface is the part that transfers best, since an SDK, a CLI and an API are what an integration needs, and that is where anything worth salvaging from the tag lives.

The workload was untrusted generated code, so the end of fixes is the real cost

Read the product description closely and the nature of the workload is explicit. Daytona is described as a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows, and sandboxes are described as full composable computers with complete isolation, each with a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM and disk. The stated purpose is agent workflows, with stateful snapshots enabling persistent agent operations across sessions.

Every one of those words points the same way. The code being executed is written by a model, and the only reason to isolate it is that it is not trusted. A dedicated kernel per sandbox and complete isolation are claims about the blast radius of code nobody has read.

That makes the end of the release line a security event rather than a maintenance inconvenience. A runtime that executes untrusted code depends on isolation being correct, and isolation correctness is exactly the kind of property that gets found to be wrong by someone probing it. A fix for a sandbox escape is not a feature, it is a patch to the boundary, and there is no longer a public line to receive it.

The consequence for anyone still running the frozen tag is direct: the isolation guarantees were the product, the code implementing them is frozen at a June 2026 state, and the README states that it comes without support or warranty. Whatever assurance remains is assurance you established yourself, on someone else's isolation design, with no upstream to tell you it broke.

Under 90ms from code to execution, and no way to check it from here

Two performance claims anchor the pitch. The README says sandboxes spin up in under 90ms from code to execution, and it attributes the speed to OCI and Docker compatibility, massive parallelization, and unlimited persistence. It names Python, TypeScript and JavaScript as the runtimes, and lists SDKs, an API and a CLI as the ways to drive it, with operations spanning sandbox lifecycle management, filesystem operations, process and code execution, and runtime configuration through base images, packages and tooling.

These are the project's own figures and they are stated without conditions in the README, which means they are also unverifiable from the repository. There is no benchmark file, no methodology, no hardware description and no percentile, and there is no longer any code to run the measurement against.

A sub-100ms cold start is the number that would decide an architecture if you were choosing a runtime for an agent loop, because a loop that waits two seconds per step behaves differently from one that waits ninety milliseconds. It is exactly the kind of claim that deserves a condition attached, and this one does not get one, which is a fair thing to notice about a project that has been frozen rather than argued with.

What survives the freeze is the shape of the design, which is well described: per-sandbox kernel and filesystem, OCI-compatible images, snapshots for cross-session state, and a programmatic surface for agents rather than a human dashboard. The numbers do not survive, and the README's own silence about how they were measured is the honest limit on what anyone can conclude from it.

Editorial conclusion

Daytona is a case to read as a signpost rather than a dependency, because the thing the repository offered is a pointer to a private codebase and a frozen tag. The last release under the open terms is v0.190.0 from 2026-06-23, and the code behind it has to come from that tag or from a fork taken before the move, since the default branch contains no source at all. If you are evaluating sandbox infrastructure for running generated code today, treat this project as a source of design ideas and of things to check in a current product, and put the weight of the decision on isolation guarantees, fix delivery and support terms rather than on the feature list, which is what stopped being true here.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes