Dora NodaDaytona used to be the sandbox you could take home. In June 2026 the company moved its core development into a private codebase, and the meaning of "self-hostable" quietly shrank from "run the whole platform on your machines" to "run some compute on your machines, under our control plane."
That is the whole story in one paragraph. The public repo is still there, frozen at v0.190.0 under AGPL-3.0, free to fork but receiving no fixes. The Helm charts still install things on your Kubernetes cluster. But the thing they install is no longer the platform — it is the edge of someone else's platform. If you evaluate sandbox vendors by checking whether a Helm chart exists, you will get this one wrong, and you will keep getting others wrong the same way.
Here is the before/after this post will defend:
| Question | Before June 2026 | After June 2026 |
|---|---|---|
| Where does the control plane run? | On your cluster: API, scheduler, PostgreSQL, Redis, S3 state, all from the public repo via Helm or Docker Compose | On Daytona's infrastructure, always |
| What runs on your cluster? | Everything, if you wanted it to | Runners and regional proxies you register back to Daytona (bring-your-own-compute) |
| Who ships security fixes to the code you run? | Upstream, in the open | Nobody — the public repo is unmaintained, "as is and without support or warranty" |
| Can you air-gap it? | Yes, in principle | No — runners phone home to a control plane you don't operate |
| What is "self-hosting Daytona" now? | Self-hosting | BYOC under a vendor control plane |
The rate sheet did not change. The trust model did. This post walks through exactly what moved, why the control-plane/compute split is the only distinction that matters, a five-question checklist to run on any vendor's "self-hostable" claim, and where the genuinely self-hostable alternatives stand now.
What actually changed in June 2026
The facts are short and well documented. The banner on the public repository reads, in full: core development moved to a private codebase as of June 2026; the repo remains public and free to use, fork, and build on under its license, as is and without support or warranty.
The last open release was v0.190.0, licensed AGPL-3.0. That version number matters because it is the entire basis of the community continuation effort: Nightona, a community fork announced July 2, 2026, picks up exactly v0.190.0 and nothing after it. Package renames are planned but nothing has been published yet, so the only prebuilt SDK artifacts from that lineage are still Daytona's own v0.190.0 packages.
The stated reason, as recorded in the sandbox-ecosystem trackers that updated Daytona's profile that August, was AI-assisted exploit discovery against public isolation code. That deserves a fair reading: Daytona sandboxes boot in under 90 milliseconds precisely because the default isolation is plain OCI containers on a shared kernel, with Kata Containers, gVisor, or Sysbox as options rather than the default. Publishing the exact implementation of a shared-kernel boundary while AI-assisted fuzzing keeps getting better is a real dilemma, and Daytona's answer was to pull the implementation dark. Whether you agree with the call or not, treat it as data about the architecture: the product's headline speed number and its need for secrecy come from the same design choice. E2B's always-on Firecracker microVMs, with a dedicated kernel per sandbox and ~150–200 ms starts, never faced the identical tradeoff at the identical intensity.
The ecosystem reacted the way ecosystems do. The awesome-sandbox index flipped Daytona's profile to "no longer self-hosted, moved closed-source." At least one downstream project now lists Daytona as dead for self-host purposes with a pointer to the archived state. None of that is moral judgment — it is operators updating a capability matrix when a capability left.
Before and after: what "self-host" used to install
Before June 2026, self-hosting Daytona meant deploying Daytona Core Services onto your own Kubernetes cluster from the public Helm chart: the API and control-plane services plus their supporting state — PostgreSQL, Redis, S3-compatible storage, an identity provider — either as external components you already ran or as built-in subcharts in the same cluster. A Docker Compose stack covered the single-node case. Runners registered to a control plane you operated, holding your own keys, audit logs, and snapshot/volume state. That is what "self-hosted" meant, and it was real.
After June 2026, the Helm surfaces that remain are the runner side. The documented bring-your-own-compute path uses a region chart that deploys a proxy service, an optional snapshot manager, and a registration job, letting sandboxes execute inside your Kubernetes cluster. Execution is yours. Everything that decides what executes, who asked, what it may touch, and what gets recorded is not: organizations, sandbox/snapshot/volume/runner records, secrets, audit logs, and the control-plane REST API live on Daytona's side. Your cluster holds compute. Their infrastructure holds authority.
Two misunderstandings keep showing up, so let's clear them directly. First, "the repo is still public" is true and almost irrelevant for production use. An unmaintained isolation runtime with no upstream security fixes is not a dependency — it is a fork you now own, including the next CVE. Second, "we run runners in our VPC" is true and beside the point for sovereignty. Data-plane locality is not control-plane ownership. If the scheduler, the identity provider, and the audit trail answer to someone else's deployment, you have outsourced the platform and kept the electricity bill.
Why the control plane is the only part that matters
A sandbox platform splits into two halves with very different trust properties. The data plane runs untrusted code inside isolation boundaries. The control plane decides which untrusted code runs where, with whose credentials, under whose policy, and it remembers everything afterward. When vendors say "self-hostable," they sometimes mean the first half. Operators almost always need the second.
Run the split concretely against what a team actually depends on:
- Identity and keys. The control plane mints sandbox tokens, brokers registry credentials, and injects secrets. Whoever operates it can impersonate any workload it schedules. Runner-local config cannot fix that.
- Audit and attribution. Sandbox create/exec/destroy records, snapshots, volume mounts, network-limit decisions — all control-plane state. If the audit log lives on someone else's PostgreSQL, your incident review starts with a support ticket.
- Security-fix flow. Isolation bugs are found continuously now, some with AI assistance. Before, the fix path was pull upstream. Now the public tree gets nothing, so the fix path is backport it yourself or trust the hosted control plane plus whatever runner build you pin. There is no third option.
- Availability and air-gap. A hosted control plane means no fully offline operation, no air-gapped region, and a hard dependency on the vendor's uptime for every sandbox start — including sandboxes running on your own nodes.
- Lock-in shape. Runner APIs, snapshot formats, and SDK calls (
create,process.exec, filesystem/Git/LSP/process/PTY helpers across TypeScript, Python, Ruby, Go, and Java) keep working either way, which is exactly why the lock-in is quiet. Migration cost is not rewriting SDK calls. It is re-homing state and policy you never held.
None of this makes bring-your-own-runners useless. Keeping execution inside your VPC solves data-residency for sandbox contents and can cut egress cost. Just price it honestly: it is a deployment option inside a SaaS relationship, not self-hosting. The moment the control plane left the public repo, Daytona moved from the first category to the second.
The five-question self-hosting checklist
Use this on every sandbox vendor, Daytona included, before the word "self-hosted" enters an architecture doc. Each question needs a yes with a pointer, not a paragraph of reassurance.
- Can I run the control plane — API, scheduler, state — from public source on my infrastructure? Pass means a repo, a release train, and a Helm chart or Compose file that produces a working control plane with no vendor endpoint in the loop. Daytona fails this today. Beam's AGPL runtime passes it. Microsandbox's Apache-2.0 single-node runtime passes it at single-node scope.
- Who holds the signing keys, identity provider, and audit log? If the answer involves the vendor's hosted service, you have BYOC, not self-hosting. Name the database each record lives in.
- What happens to my deployment the day upstream stops publishing? The Daytona answer is now observable: you hold v0.190.0 plus your own backports. Ask it hypothetically of every vendor and discount any "the repo will always be there" answer by the maintenance half-life you just watched play out in six weeks.
- Does the license let me keep running and fixing it without the vendor? AGPL-3.0 (Daytona v0.190.0, Beam) says yes with copyleft obligations. Apache-2.0 (Microsandbox) says yes with fewer strings. A private codebase says no regardless of what the old repo's license still permits for the old tree.
- Can it start a sandbox with the vendor unreachable? Pull the network cable — on paper first, then in staging. Anything that needs to phone home to schedule is SaaS with local executors. A genuinely self-hosted control plane starts sandboxes in an outage; a BYOC runner fleet waits.
Five yeses is self-hostable. Four is a negotiation. Three or fewer is a managed service with a Helm chart, and should be budgeted, risk-reviewed, and exited as one.
Where to go instead, honestly scored
Nobody gets everything Daytona's open era offered — sub-90 ms starts, Docker-ecosystem familiarity, Kubernetes-native deployment, five SDK languages — in one package today. Pick by the constraint that actually binds you.
- E2B. Firecracker microVMs, ~150–200 ms cold starts, per-second billing at the same $0.0504/vCPU-hr plus $0.0162/GiB-hr parity point Daytona shares. Stronger default isolation than Daytona's container default, weaker self-host story than the old Daytona. Choose it for isolation strength per sandbox, not for sovereignty.
- Modal Sandboxes. gVisor-backed, snapshot-capable, the only one of the three with first-class GPU sandboxes and zero-while-idle billing. Not self-hostable. Choose it for bursty GPU-capable agent work you want metered to zero, and stop pretending it is infrastructure you own.
- Beam. The nearest Modal-shaped option with an AGPL-3.0 open-source runtime you can run yourself — runc/gVisor containers, sub-second starts, snapshots and log streaming. Isolation is container-grade rather than microVM-grade, so scope it the way you would scope any container sandbox. Choose it when control-plane ownership matters more than per-sandbox kernel isolation.
- Microsandbox. Apache-2.0, self-hosted by design, snapshot/fork/restore shipped — but a single-node runtime, not a fleet scheduler. There is a broader pattern here worth naming bluntly: one recent survey of the space concluded every agent-sandbox project is either a managed cloud you cannot self-host or a single-node runtime you cannot scale past one machine. Microsandbox is the best-behaved instance of the second kind. Choose it for local and single-box agent execution, not as a multi-tenant fleet.
- Nightona (community fork of Daytona v0.190.0). The honest continuation play: same AGPL-3.0 tree, Docker Compose plus Helm surfaces as its stated focus. Four stars, no published packages yet, SDKs built from source. Betting on it means betting you and a tiny community can carry an isolation runtime's CVE load indefinitely. That is a real option for a team with platform headcount and a bad fit for anyone who chose Daytona originally to avoid exactly that burden.
If your roadmap says "agent sandboxes on machines we already run," the remaining honest primitive is the one no vendor can close: gVisor or Kata isolation scheduled as pods on a Cluster-API fleet you operate, with your own API in front. It is more engineering than adopting a runner chart and less surprise than adopting a control plane you don't own. That is the trade the Daytona episode prices correctly.
The lesson that outlives Daytona
Daytona's team faced a genuine dilemma — public isolation code under AI-assisted scrutiny — and picked vendor safety over user sovereignty. You can disagree with the choice while updating your vendor template because of it. "Has a Helm chart" never meant self-hostable. "Runs in my VPC" never meant self-hostable. The control plane is the platform, and the only self-hosting claim worth anything names where the control plane runs, who fixes it, and what happens when the publisher walks away.
Ask those three things up front and the next quiet narrowing — whoever does it next — will read as a line item in a risk register instead of a surprise in a changelog.
Daytona's June 2026 move is a reminder of why the boring architecture wins: infrastructure you can still run when the vendor's roadmap turns. 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.
