Daytona's Core Went Private: What a Frozen Sandbox Repo Teaches About Who Owns Your Agent Isolation Layer

There is a special kind of open-source death that doesn't look like death at all. The repo stays up. The stars stay counted. The license still says you can fork it. All that changes is a banner at the top of the README — and one day your agent platform's isolation layer stops getting fixes forever.

In June 2026, that banner landed on daytonaio/daytona, one of the most-starred sandbox runtimes in the AI-agent era:

This repository is no longer maintained. ... As of June 2026, Daytona's core development has moved to a private codebase. ... It remains public and free to use, fork, and build on under the LICENSE, as is and without support or warranty.

No shutdown announcement. No migration guide. No deprecation timeline. Just a maintenance-mode README on a project a third-party audit counted at roughly 72,000 stars — and a pointer to the company's new home at github.com/daytona, where the live product is now a managed control plane with bring-your-own-compute. If you built your deploy-from-chat stack on Daytona's open-source runtime, this post is the concrete accounting of what that freeze costs you, the options you actually have with honest prices attached, and the checklist that would have warned you before the fork went stale.

The README that froze the repo​

To be precise about what happened — because precision is the whole point — Daytona didn't delete anything. The AGPL-licensed stack (dashboard, runner, SDKs) is still public and self-hostable at its final release, v0.190.0. What moved behind closed doors is core development: all future fixes, security patches, and releases now happen in a private codebase that feeds the commercial product. Your fork compiles today and will compile next year. It just will never get better, and every CVE discovered in it from June 2026 onward is yours to patch.

The road to the freeze took three years and two identities:

Read that timeline again and notice the shape: open-source distribution builds the audience, a pivot redefines the product around AI agents, a large round sets the commercial clock ticking — and four months after the Series A, the public repo stops moving. That shape is not an accident and not unique. It is a playbook, and Daytona is only its latest run.

Frozen but forkable: what that actually costs you​

"Free to fork under the license" sounds generous until you price what the fork inherits. Staying on the frozen repo means owning all of this:

Every future CVE is now your patch to write. A sandbox runtime is an isolation boundary for untrusted, machine-generated code — the single worst layer in your stack to stop receiving upstream security fixes. Container-escape mitigations, dependency updates in the runner, kernel-interface changes: the vendor's private codebase will get them, your fork will not, and backporting from a binary you can't see is not a plan.

The AGPL maintenance burden is real work, not a footnote. Daytona's frozen stack is AGPL-3.0. Forking it for internal use is fine, but operating a fork means tracking upstream-adjacent dependency upgrades yourself, carrying your own CI for a codebase whose maintainers left, and — if you distribute or network-serve modified versions — honoring copyleft on code you now solely maintain. Teams routinely underestimate this at "a few hours a month" and discover it is a part-time platform engineer.

The ecosystem drifts away from your pin. SDKs, examples, community fixes, and third-party integrations follow the live product at github.com/daytona, not v0.190.0. Within a year, "Daytona-compatible" in the wild will mean the managed API surface, and your frozen fork will be a dialect only you speak. Hiring someone who knows it, finding a fix someone else already wrote, getting an answer on a forum — all of it decays from the freeze date.

The vendor's supported path is now managed or BYOC. Daytona the company is fine; Daytona the open repo is frozen. If you want supported Daytona behavior going forward, the road on offer is the managed control plane (or BYOC compute under it) — a commercial relationship with commercial pricing, not a self-hosted runtime you control. That may be a perfectly good deal. It is just not the deal you signed up for when you adopted an open-source isolation layer.

Add it up and the freeze converts a dependency into a liability on a schedule: free today, a maintenance tax within quarters, a forced migration within a year or two. The only question is whether you choose the migration or the CVEs choose it for you.

MinIO CE ran this exact play in February​

If this feels familiar, it should. Four months before Daytona's freeze, MinIO's Community Edition hit the same terminal state: the public repo marked as no longer maintained in February 2026, the web console already removed from the community build in 2025, and all living development moved into AIStor, the enterprise product. Different layer — object storage instead of agent sandboxes — identical shape:

Two marquee open-source projects, same year, same terminal state: public, forkable, and frozen. That is the pattern to internalize. The modern OSS-to-commercial endgame is rarely a license rug-pull or a repo deletion — those make headlines and forks with momentum. It is a quiet README banner that strands you on a version that will never improve, announced on no schedule you were watching. Once you see MinIO and Daytona as the same event, the right response stops being "migrate off Daytona" and becomes "build a policy for every VC-funded OSS dependency you run."

Your options, priced honestly​

Concretely, from a frozen Daytona fork, there are four doors, and three of them are honest choices. Here they are with the isolation model and the real price of each:

Which door depends on where you are:

• Solo dev / prototype: door C. Wrap one sandbox API behind your own interface, keep sessions ephemeral, and don't build anything that assumes the provider's OSS repo stays alive. E2B's Firecracker isolation and clean SDKs are the fastest path; add Modal when you need GPUs.
• Funded team shipping an agent product: door B or C with a door-D plan. Renting is correct while sandboxing is not your differentiator — but put the provider behind an abstraction you own, because doors B and C both rent the isolation layer from someone whose roadmap you don't control. Daytona just demonstrated the failure mode.
• Platform team / self-hosted PaaS: door D. If agents deploying code is your core loop, the isolation boundary is load-bearing infrastructure, and load-bearing infrastructure belongs on primitives no single vendor can freeze. Upstream Kubernetes agent-sandbox (gVisor by default, Kata where you need VM-grade boundaries) plus TTL-based cleanup and per-tenant quotas gives you the lifecycle without the README risk.

Note what doors C and D share: neither depends on a single company's open-source generosity surviving its next funding round. That is the actual lesson. The question was never "is Daytona good technology" — it clearly was, which is why 72,000 stars showed up. The question is "who can freeze the layer my agents execute inside," and any answer that is one company's name is a risk entry, not an architecture.

The early-warning checklist​

The freeze banner is the last signal, not the first. Here is the checklist that catches the next Daytona while there is still time to plan — applicable to any VC-funded open-source dependency, not just sandboxes:

1. Funding-to-freeze lag. A large round after an OSS-led growth phase starts a 3–6 month clock. Daytona's Series A landed February 5; the repo froze in June. When your dependency raises big, calendar a re-evaluation — the round is the announcement, the banner is just the confirmation.
2. Pivot language in the boilerplate. "Open-source dev environment manager" became "secure infrastructure for running AI-generated code" a full year before the freeze. When the company's self-description stops mentioning open source, believe the new description.
3. Commit-velocity and maintainer tells. Fewer community-facing commits, roadmap discussions moving to private channels, enterprise features shipping without OSS counterparts (MinIO's console removal is the textbook case). Watch the repo's pulse, not its star count — stars only ever go up.
4. New-org / new-repo drift. Daytona's living resources now sit at github.com/daytona, a separate org from the frozen daytonaio/daytona repo. When a vendor's fresh docs, SDKs, and examples point somewhere the old repo doesn't, the old repo is already legacy.
5. Single-vendor governance. One company holding all commit rights, the trademark, and the hosted offering means one board meeting can end the OSS project. CNCF-governed primitives (Kubernetes agent-sandbox, gVisor, Kata) can't be frozen by a funding event because no single cap table controls them.

Run this checklist quarterly against every open-source layer you treat as load-bearing. It takes an hour. The alternative is learning about your isolation layer's end-of-life from a README banner — four months after the signal that would have let you plan.

Own the layer the agents run inside​

Daytona's arc — beloved open-source tool, agent-era pivot, big Series A, quiet freeze — will repeat, because the incentives repeat. Open source is unmatched at distribution and terrible at guaranteeing a future. For everything above your isolation boundary, that tradeoff is fine. For the boundary itself — the thing standing between untrusted generated code and your infrastructure — "frozen but forkable" is not a posture, it is a countdown.

The durable answer is boring in the best way: build the execution layer on primitives no vendor can take private, run them on machines you control, and rent the managed APIs only behind interfaces you own. That is how you get sandboxes without README risk.

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.