Daytona's Repo Is Frozen — Will the Fork Survive? What Three Open-Source Relicenses Teach About Betting on Nightona

In June 2026, Daytona — over 70,000 GitHub stars, $31 million raised, pitching "a computer for every agent" — froze its public repository at v0.190.0 and moved core development into a private codebase. The repo is still there. So is a community fork, Nightona, carrying the last open release forward under AGPL-3.0. Here is the verdict up front: the fork exists, but history says forks survive only under three conditions — neutral or consortium governance, funded full-time maintainers, and an API-compat incentive — and Nightona today checks maybe half of one.

If you built on the open Daytona, the question is not whether the code still runs. It is whether anyone will still be patching it in a year, and three previous relicenses give a brutally clear answer key.

This post is the history-pattern companion to our buyer's guide, Daytona Went Closed-Source: What It Costs to Build Agent Sandboxes on Borrowed Open Source, which prices the CVE, drift, and AGPL bills and compares the remaining self-hostable field. Read that to pick a replacement; read this to decide whether the fork deserves to be on the shortlist at all.

What "the repo is still there" is actually worth​

Daytona's arc compressed a decade of open-source business-model evolution into about eighteen months. Founded in 2023 by Ivan Burazin, it went open source under Apache 2.0, pivoted from dev environments to AI-agent sandbox infrastructure in early 2025, relicensed to AGPL-3.0 during the pivot, then raised a $24 million Series A in February 2026 led by FirstMark — reportedly hitting $1 million in ARR in under three months on customers including LangChain, Turing, Writer, and SambaNova. The product earned its reputation honestly: sub-90ms sandbox cold starts, OCI containers with optional Kata isolation, stateful long-lived agent workspaces.

Then the timeline turns:

The README says it plainly: "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 fork "as is and without support or warranty."

So what is the frozen tree concretely worth? An honest ledger:

The third row is the one that matters. A sandbox vendor's isolation primitives are the exact layer under automated adversarial review — the stated reason for going private — which means the frozen tree stops receiving fixes for precisely the vulnerabilities most likely to be found in it. That is not a reason to panic-delete a working deployment today. It is a reason to price the fork you would depend on tomorrow against what history says forks need.

Three relicenses and what happened next​

Daytona is not the first beloved open-source project to close the door, and each previous episode left a fork whose fate is now a matter of record. Three cases, three outcomes:

Three different triggers, three different years — and the same three survival conditions every winning fork had:

1. A backer with money and a neutral home. No winning fork was a volunteer effort. OpenTofu launched under the Linux Foundation with companies paying engineers to work on it. Valkey had AWS, Google, and Oracle behind it within days. OpenSearch had AWS's full weight, then a dedicated LF foundation.

The pattern is measured, not just narrated: CHAOSS's Dr. Dawn Foster presented research at State of Open Con '25 tracking contributor and adoption flows after the Terraform, Redis, and Elasticsearch relicenses — and the consistent finding is that ecosystems follow funded maintenance, not sentiment.

2. Funded, full-time maintainers from day one. This is condition one restated as headcount, because it is the part volunteers cannot fake. A fork that nobody is paid to maintain gets weekend commits until the first hard CVE, then silence. Every surviving fork had payroll behind it before the announcement-week enthusiasm faded.

3. An API-compat incentive that makes migration free. Valkey spoke the Redis protocol, OpenTofu read Terraform configurations, OpenSearch answered Elasticsearch APIs — so each fork inherited the original's entire ecosystem of client libraries, tooling, and operator muscle memory on day one. Compatibility is what converts outrage into adoption: users switch with a version bump instead of a rewrite, and the fork gets a user base large enough to justify the payroll in condition two. Note the feedback loop runs both ways — the two cases where the original vendor later returned to an OSI-approved license (Redis to AGPLv3, Elastic adding AGPLv3) happened only after the compatible fork had already siphoned enough momentum to force the reversal.

No fork in this table survived on community goodwill alone. Every one that thrived had a foundation or a cloud vendor writing checks and a compatibility story that made switching costless.

Nightona against the pattern​

Now score the Daytona fork against the same three conditions:

That is half a point out of three, and the half-credit row decays over time: every hosted-only feature Daytona ships makes "compatible with Daytona" mean less for a tree pinned at June 2026. Contrast this with Valkey, whose compat target (the Redis protocol) was stable, open, and worth cloning. Nightona's compat target is a private codebase whose owner has no reason to keep it cloneable.

To be fair, the scoreboard is not destiny. Forks have graduated from worse starting positions when a foundation adopted them or a vendor consortium discovered a shared interest in funding them. But that rescue has to come from somewhere concrete — a named backer with payroll — and three months after the freeze, Nightona has enthusiasm, which every failed fork also had in month three.

The practical read: Nightona is a lifeboat, not a ship. Pinning a development dependency to a community-maintained v0.190.0 while you migrate is rational. Building a production agent-sandbox layer on it — isolation-critical code, maintained by volunteers, drifting permanently from the commercial API — is betting against every precedent in the table above. If you need the sandbox to outlive your current sprint, the money is on runtimes that already clear the bar in the next section, or on a SIG-governed project like kubernetes-sigs/agent-sandbox that no board meeting can take private.

The procurement bar: Apache-2.0 plus active maintenance​

The Daytona episode teaches a procurement rule that fits on an index card: a public repo is not open-source infrastructure. Infrastructure is a permissive license plus living maintenance plus governance you can verify. Before the next sandbox — or database, or queue, or identity provider — becomes load-bearing in your platform, check five things:

1. Permissive license (Apache-2.0 or equivalent). Copyleft is not disqualifying, but AGPL network obligations on infrastructure you modify and serve must be a deliberate legal posture, not a surprise during diligence. Daytona's Apache-to-AGPL step during its 2025 pivot was the early warning; the June 2026 freeze was the event it warned about.
2. Living commits plus a security feed. Check releases and CVE responses in the last 90 days, not the star count. Seventy thousand stars did not ship a single patch after June 2026.
3. Governance that survives a board vote. Foundation or SIG stewardship, a real vendor consortium, or at minimum a credible second company with commit rights and commercial interest. Single-vendor OSS is a feature flag the vendor can flip — price it as one.
4. A self-host path that is a tested CI artifact. If self-hosting is not exercised in the project's own CI, it is already deprecated in everything but the docs. Ask which release job proves the self-hosted path works; accept no README paragraph as a substitute.
5. An interface you own. Put the sandbox behind a small harness interface you define — spawn, snapshot, exec, teardown — so Daytona-today or Microsandbox-tomorrow are backends, not foundations. The teams hurt by June 2026 were not the ones using Daytona; they were the ones fused to it.

Run the surviving sandbox field through this checklist and the results rhyme with the buyer's guide: E2B's self-hosted path is Apache-2.0 but second-class by design, Microsandbox is permissive but single-vendor young, and only the SIG-governed agent-sandbox clears the governance row without qualification. No option scores five for five — which is exactly why item five exists.

Watch the payroll, not the repo​

Three things will tell you, over the next two quarters, whether this episode ends like Redis or like a dozen forgotten forks: whether Nightona gains a named institutional backer or stays volunteer-run, whether the kubernetes-sigs agent-sandbox project converts vendor attention into a stable release operators actually deploy, and whether E2B's self-hosted posture improves or quietly follows Daytona toward hosted-only. Stars, sentiment, and the continued existence of a public repo will tell you nothing — all three survive every rug-pull by definition.

The durable lesson is simpler than any scorecard: depend on maintenance, not on availability. A frozen repo you can read is worth exactly the CVEs you are willing to backport yourself. Everything else — the patches, the features, the parity — was never the code. It was the payroll behind the code, and payrolls move.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.