Daytona2 targets the agent runtime gap that Kubernetes leaves open

Why Kubernetes strains under agent workloads

According to Daytona, many teams extend their existing Kubernetes infrastructure to run agents because it already powers their production applications. The company argues that this works at first but starts to break as workloads scale. Teams then layer on extra systems, which Daytona describes as "a patchwork of workarounds and fragile dependencies."

The post says Kubernetes became the standard control plane by reliably running containerized workloads, and its pod-based design suits long-running microservices and horizontally scaled APIs, where instances are interchangeable and state is decoupled from compute. Agents, Daytona argues, need short-lived, task-specific environments with varying execution patterns, and the infrastructure must adapt in real time while carrying context across steps.

Daytona is explicit that the answer is not abandoning Kubernetes. Its position is that the stack is missing an execution environment built for how agents behave.

Five pain points Daytona identifies

The post groups the problems into five areas.

• Orchestration complexity: each agent task needs its own environment with a dedicated filesystem and lifecycle. At thousands of concurrent tasks, teams write controllers to provision sandboxes, track active ones and clean up afterward. Daytona says each extra step adds failure modes, including orphaned sandboxes that consume storage other workloads need.
• Provisioning latency: a coding agent fixing a production bug must wait for Kubernetes to create capacity, schedule the pod, pull the image and initialize the runtime. Even if each step takes only seconds, Daytona says the delay accumulates across tasks and limits throughput.
• Isolation overhead: because agents generate code and modify files, each environment needs strong isolation, typically gVisor or Kata Containers plus CNI plugins such as Cilium or Calico for egress rules. Daytona says Kata Containers significantly increases baseline resource consumption, while shared-kernel approaches like gVisor slow I/O and create potential escape paths.
• Repeated context reconstruction: preserving workspace state requires PersistentVolumeClaims, external stores and CSI-backed snapshots. When these custom builds fall short, agents reconstruct context and environments can drift between executions.
• Inefficient resource utilization: demand can jump from idle to hundreds or thousands of environments. Daytona gives the example that keeping 500 sandboxes pre-warmed can mean reserving 500 vCPUs and 1 TB of memory before agents start work. A smaller pool means agents queue during surges.

What Daytona offers

Daytona says its platform removes the need to build this layer. Teams get a fully managed sandbox platform, with the option to deploy the runtime onto their own clusters while keeping Kubernetes as the control plane.

The company says its orchestrator, using a Declarative Builder for environment definition, provisions and manages self-contained, single-instance sandboxes across cloud infrastructure, VMs and bare-metal servers. Each sandbox has its own resources and lifecycle, which Daytona says gives agents a consistent runtime regardless of the underlying infrastructure.

On speed, Daytona says it provisions sandboxes on demand from pre-warmed snapshot templates instead of maintaining an idle pool of warm sandboxes. According to the company, the platform provisions new Firecracker microVMs in under 90ms, which it says keeps interactive agent workflows responsive.

As a customer example, Daytona says Trajectory saves 15+ hours each month that were previously spent stitching together solutions on top of Kubernetes, and also gets more predictable infrastructure operations. These figures come from Daytona's own post.

What it means for teams building agents

The argument is aimed at engineering teams that have already put agents on Kubernetes and are spending time on custom controllers, warm pools and storage layers. Daytona's pitch is that a dedicated runtime lets those teams concentrate on agent behavior and iterate faster on new workflows. Its claims about performance and time savings are the company's own, and the source text provided does not include independent benchmarks.