Clarion Street

Daytona's Archived Repo and the Year-Three Sandbox Question

·13 min read

GitHub archived daytonaio/daytona on 3 October 2026. The banner is the plainest kind of notice: “This repository was archived by the owner on Oct 3, 2026. It is now read-only.”

The README explains what happened, in the repository’s own words:

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 use, fork, and build on under the LICENSE, as is and without support or warranty.

At archive the project had 71,488 stars and 5,639 forks (GitHub API, queried 25 October 2026). Its default branch now holds two entries, README.md and assets. Every source file is gone from main. What survives is the tag history: v0.190.0, published 23 June 2026, whose LICENSE is the GNU Affero General Public License v3.0.

Daytona is one of the two open-source sandbox platforms that keeps appearing in these comparisons, including one here, where it turns up in OpenAI’s list of nine compute partners. In June it was a 71,000-star open-source runtime. By October it was a read-only page with a stripped default branch.

I have not found a company statement explaining the move. No blog post, no press release, nothing I could point a reader at. The freeze is documented by the repository notice, the archive date and the tags, and by nothing else I could locate. I will not guess at a motive.

What the isolation argument already settled

The technical half of this debate is not close, and I have written the analytical version of it before in Beyond the Sandbox, so I will not re-argue it here. Firecracker gives each workload its own guest kernel under KVM and treats every vCPU thread as hostile from the instant it starts: “considered to be running malicious code as soon as they have been started” (design doc). gVisor puts a reimplementation of the Linux interface between the application and the host kernel. Kata does VM-per-pod and can run on QEMU, Cloud-Hypervisor or Firecracker, which is why the three compose more than they compete (katacontainers.io).

The one line from that material I want to keep is gVisor’s own answer to a FAQ question about hardware side channels. “In general, gVisor does not provide protection against hardware side channels” (security model). Every platform sells isolation as the security property. The most careful of the isolation projects says, on its own documentation page, where its protection stops.

That concession matters for what comes later. A boundary drawn at the kernel is a boundary against a class of exploit. It says nothing about whether the machine your sandbox is running on is the machine you think it is, or whether the secret your agent just received was released to the workload it was meant for.

What an archive actually costs you

A vendor going closed-source is a business decision, and a customer who never self-hosted was never exposed to it. I am also not sure this is a security story at all. What that customer’s hosted sandbox did on 4 October is a separate question, and the notice on the repository does not answer it. It says the public repository gets no further updates, fixes or releases. It says nothing about what Daytona does with its own service, and I could not find a support statement either way. I am not going to claim hosted users were left exposed, and I am not going to claim they were fine. The people whose loss is documented are the ones who had built on the open repository, forked it, or planned to. That is a real group, but it is not everyone, and I would rather say so than inflate the event.

For those people the loss is specific. An archived repository does not stop working. It stops receiving fixes. If a vulnerability lands in the daemon, the API server, the container runtime or the SDK, nobody upstream is going to ship a patched version of v0.190.0, and the notice says as much before the archive even happened: no further updates, fixes or releases. Patching is the single most boring security control there is, and it is the one that quietly disappears when a project stops.

The escape hatch is technically real and practically thin. Nightona picks up the last open release and describes itself as “the open-source continuation of Daytona,” starting from “the exact v0.190.0 codebase” under AGPL-3.0. It preserves the LICENSE, COPYRIGHT and NOTICE files, which is what the license requires. Its README includes the sentence I would have written if I were being cruel: “Because the sun set on the open-source Daytona — and this project keeps the lights on.”

The traction, as of 25 October: 23 stars, 7 forks, last push 28 September (API), against 71,488 stars on the parent repository. A fork is not a control, and a fork with 23 stars is not a support contract. It may grow, and one month of history is not a verdict, but it has not replaced the vendor and there is no evidence yet that it will.

One more detail that matters commercially, and I want to flag it as a question rather than an answer. AGPL-3.0 is network copyleft. If you embed a Daytona-derived core in something users reach over a network, the license has opinions about what you then have to publish. I am not a lawyer and this is not legal analysis, but a team adopting the v0.190.0 tag to keep a fork alive should put that question in front of counsel before they ship, not after.

The counter-example, and the line its own author wrote

E2B went the other direction, in public, on 30 September. E2B Embed installs its stack on infrastructure you own: Docker Compose on a Linux host with KVM, Terraform on GCP or AWS, or kubectl apply -k against a cluster with a prepared KVM node. “You do not need an E2B account or a license key.”

The licensing is verifiable independently of the marketing. The GitHub API returns Apache-2.0 for both e2b-dev/E2B (14,547 stars) and e2b-dev/runtime (1,767 stars), and reports both as last pushed on 24 and 25 October. That field records a push, not a commit count, so I will not read a commit rate off it. It is still the difference between two repositories with activity this week and one that has been read-only since 3 October.

E2B’s marketing makes the license the security argument: “Audit the code, not a whitepaper” and “Open source means the exit door stays open.” I think that is a good argument, and it is also a claim about the boundary rather than about the thing above the boundary.

Which brings me to the sentence I keep rereading, in the Embed announcement itself: “E2B Embed does not include secrets, volumes, workload identity or bring-your-own proxy.”

Read that next to what E2B’s hosted product does. Its own comparison describes “network rules that allow or block destinations by IP, CIDR, and domain,” cloud metadata blocked by default, and “secret injection [that] adds credentials at the network proxy, keeping their actual values outside the VM and unavailable for code inside it to read.” That is the control that decides the blast radius when an agent is compromised. And the self-hosted path, the one with no account and no key, does not ship it.

I do not think E2B is being deceptive about this. They wrote it down, in the announcement, in one sentence, without spin. But it means the free path gives you the isolation layer and leaves the credential mediation to you, which is the harder half to build and the half most teams underestimate. The Apache-2.0 boundary is real and the auditability pitch is honest. What you get for zero dollars is narrower than what the company runs.

E2B’s description of itself as “the only open-source hosted microVM sandbox platform” is positioning, not an audited category, and its own Embed page calls the product “a single-machine product,” with scaling across machines and vendor-operated deployments routed to Bring Your Own Cloud. Self-hosting and operating at scale are different purchases.

Warm pools and their limits

Both of the serious Kubernetes answers now hold environments ready before anyone asks for one. Red Hat’s Agent Sandbox operator preprovisions with warm pools “avoiding cold-start VM creation” (Red Hat), and the idea is not new: the Kubernetes SIG Apps agent-sandbox project exposed a SandboxWarmPool months ago. I am not claiming novelty for it, and the coincidence of custom-resource names between the two projects is not something I could verify as a shared upstream.

A warm pool can put pressure on the property the rest of this post is about, if it fills by reusing state instead of booting fresh. Firecracker’s snapshot documentation is direct about the failure mode:

Without a strong mechanism that enables users to guarantee that unique things stay unique across snapshot restores, we consider resuming execution from the same state more than once insecure.

That covers identifiers, random number seeds, the guest entropy pool and cryptographic tokens. The docs then work through three examples and label two of them insecure. Whether either product’s pool restores snapshots or boots a fresh VM for each claim is an implementation detail I could not check for either one, and a warm pool by itself is not evidence that anything gets reused. A pool that boots each sandbox fresh from a template never meets the problem at all. The conditional version is the one worth carrying into a review: if a pool fills by restoring the same snapshot more than once, the uniqueness problem lands on it, and proving the environment is what it claims to be gets harder. That is a question to put to a vendor, and the answer will differ by implementation.

The part that holds either way is narrower: warm pooling is an availability feature, and nothing in it provides attestation. A pre-warmed sandbox is no better able to prove what it is running on than a cold one.

The half of the problem the sandbox vendors do not sell

On 4 August Red Hat shipped OpenShift sandboxed containers 1.13, Red Hat build of Trustee 1.2, and a Technology Preview of Red Hat build of Agent Sandbox.

Trustee is the part worth understanding. It is attestation-driven secret management for confidential workloads: it “releases secrets only to hardware-attested workloads, never exposing them in plaintext to cluster administrators.” Version 1.2 extends disconnected attestation to Intel TDX on bare metal and on Azure, building on existing AMD SEV-SNP support. Red Hat describes that capability as “a critical requirement for government and highly regulated, network-isolated deployments.”

Stack those two sentences. A secret is released only to a workload that has proved what hardware it is running on, and the proof works with no network path home. Neither sentence is about isolation. Isolation bounds what a compromised agent can reach. Attestation answers whether the thing receiving your credential is running where you think it is. Neither one substitutes for the other.

Agent Sandbox sits underneath and manages “the lifecycle of ephemeral, VM-isolated sandboxes” backed by Kata, exposed as Sandbox, SandboxTemplate, SandboxClaim and SandboxWarmPool resources with a router for browser, notebook and IDE access. Red Hat calls it “the substrate for the emerging Model Context Protocol (MCP) code-execution pattern” and puts GA later, with deeper MCP tool-server integration. It is a Technology Preview. Do not read this as production-ready, and do not merge it with NVIDIA’s OpenShell release from September, which I covered separately and which is a different vendor, different product and different layer. The only reason Red Hat shows up in both stories is that Red Hat is in both stories.

The same release put confidential AI on bare metal into general availability with GPU TEE attestation through Trustee and NVIDIA’s Remote Attestation Service, gated on verified hardware. What Red Hat charges for here is unusual for this market: the ability to prove what a sandbox is running on before anything sensitive goes into it. The pitch is aimed explicitly at buyers who cannot call a SaaS endpoint, and speed does not come into it.

What I would ask before signing

Five questions, and I would want the answer in writing.

What is the license of the component I am depending on, and what happens to that license if the vendor’s strategy changes in eighteen months? Ask about the last release tag, not the repository.

Can I patch it myself, and have I ever actually done so? If the answer is no, you are depending on someone else to keep it maintained, and the notice on Daytona’s README is what happens when that dependency ends. Take the tag, build it, apply a trivial fix, and see what the afternoon costs.

If I self-host, which of the product’s controls are missing from the self-hosted build? E2B answered this one in a sentence, and it is the only reason I trust the rest of their page. Ask every vendor for the same sentence.

Does anything in the deployment release a secret on the basis of attestation, or does the credential arrive by some other route? If it arrives by an environment variable in a manifest, the whole confidential-compute story above the sandbox is decorative.

Which certification covers the sandbox product rather than the vendor? Control Plane’s comparison puts it well, and then declines to rank on speed at all: “We did not benchmark cold starts.” Its table lists SOC 2 Type II or ISO 27001 for several platforms and no FedRAMP entry anywhere in it. Absence in one vendor’s table is not proof of absence anywhere, so treat it as a thing to check rather than a finding.

Two caveats on everything above. The performance and scale figures in this market are the vendors’ own; I ran no benchmarks and neither, as far as I can tell, did anyone publishing a comparison. And every source in this post is either a vendor page, a project’s own documentation or a GitHub API response. Those are reliable on mechanism and on dates. They are not evidence that any of these systems is secure, and I would not repeat a marketing adjective from any of them as a finding.

Bottom line

The isolation argument is settled enough that it is not where the risk is. The risk is that the environment you standardized on stops shipping fixes, or that you self-host the boundary and discover the credential layer was never in the box. Daytona is the first case, documented in its own README. E2B’s Embed announcement is the second, documented in its own footnote. Red Hat is the vendor currently selling the third piece, to buyers who cannot buy a hosted sandbox at all.

An agent platform is a two-to-three-year decision, and the questions above tend to surface after a proof of concept has already passed. That is later than a comparison table will help you, and a comparison table is what most teams meet these platforms through.

Sources

  1. daytonaio/daytona — archived 2026-10-03, README notice, default branch contents
  2. daytonaio/daytona LICENSE at v0.190.0 — AGPL-3.0
  3. GitHub REST API: repos/daytonaio/daytona — 71,488 stars, 5,639 forks, pushed 2026-07-24, archived: true, license null (queried 2026-10-25)
  4. GitHub REST API: repos/daytonaio/daytona/releases — v0.190.0 published 2026-06-23
  5. nightona-co/nightona — community fork, AGPL-3.0
  6. GitHub REST API: repos/nightona-co/nightona — 23 stars, 7 forks, pushed 2026-09-28 (queried 2026-10-25)
  7. Introducing E2B Embed — E2B, 2026-09-30
  8. Open Source — E2B vendor page
  9. Best Code Execution Sandboxes for AI Agents in 2026 — E2B, 2026-10-15
  10. GitHub REST API: repos/e2b-dev/E2B and repos/e2b-dev/runtime — Apache-2.0, 14,547 and 1,767 stars, pushed 2026-10-24 and 2026-10-25 (queried 2026-10-25)
  11. Firecracker design document
  12. Firecracker snapshotting support — snapshot security and uniqueness
  13. gVisor security model
  14. Kata Containers
  15. What’s new in Red Hat OpenShift confidential computing and sandboxing — Red Hat, 2026-08-04
  16. 10 Best AI Agent Infrastructure Platforms in 2026 — Control Plane, 2026-10-08