Daytona is going closed source. Here's why.
We started Daytona open source. It was a decision we believed in, and one we were proud of. The code that runs our sandboxes has been public from the beginning, and a lot of the trust we earned came from the fact that anyone could read it.
Today we are moving Daytona's production codebase to closed source. There is one reason behind this, and it is the only reason that matters to us: security.
What changed
A year ago, finding a serious vulnerability in a large codebase took a skilled researcher and real time. Most weaknesses went undiscovered simply because there were not enough people with enough hours to find them. That assumption no longer holds.
AI can now be pointed at an open source repository and systematically search it for exploitable flaws, at a speed and scale no human team can match. This is not a forecast. It is already happening, and the pace over the last six months has been hard to overstate.
In January, an AI system independently discovered all twelve zero-day vulnerabilities in a single OpenSSL release, some of them dating back twenty-five to twenty-seven years and surviving decades of expert human review. Separately, AI tooling produced well over a hundred CVE assignments across popular open source projects in a single year.
Anthropic's own research team has been clear that models can now find high-severity vulnerabilities at scale, and called this an inflection point. In May, Google's threat intelligence group reported a real attacker using an AI-assisted exploit against an open source administration tool in the wild.
The defenders are not the only ones running these tools. The same capability that lets a security team harden their code lets an attacker map it.
Why this hits us harder than most
Daytona's entire job is isolation. Customers run untrusted, AI-generated code inside our sandboxes precisely because they trust the boundary between that code and everything else. That trust is the product. A single isolation escape is not an inconvenience for us. It is a breach of the one promise the platform exists to keep.
When our isolation layer, our kernel boundaries, and our orchestration logic are fully public, we are handing the exact blueprint of that boundary to anyone who wants to test it with an AI that never gets tired and never stops. For most software, an open codebase is a manageable risk. For infrastructure whose only purpose is to contain hostile code, it is an unacceptable one.
So we faced a straightforward choice. Stay open and accept a rising risk to customer data and customer workloads, or close the source and reduce the surface attackers can study. Neither option is perfect. We chose the one that protects our customers.
What this does not change
The existing open source repository is not going anywhere. It will stay public so anyone who wants to keep using it, fork it, or build on it can continue to do so.
We will no longer maintain or update it, but it remains available as is.
Going forward, our SDKs, documentation, and guides live in a new home: https://github.com/daytona. That is where to point your integrations and where ongoing work will be published.
Our commitment to security in the open does not disappear because the code does. We will keep publishing how our isolation model works, what guarantees we make, and how we respond when something goes wrong. We will keep using these same AI tools defensively against our own systems, continuously, so that we find what an attacker would before they do.
We did not take this lightly, and we know it costs us something. If the threat landscape shifts in a way that makes openness defensible again, we want to revisit it. For now, putting our customers first means closing the source.
If you have questions about what this means for your deployment, reach out to your account team or our security team directly. We would rather have that conversation than have you guess.