Daytona raises $60 million for its agent execution cloud

Daytona announced a $60 million Series B on October 20, 2026, at a $1 billion valuation. FirstMark Growth led the round, which brings total funding to $91 million, according to the company.

Chief executive Ivan Burazin describes the goal as an execution cloud for agents, supplying the computers, browsers and storage they use to perform work. For developers, that proposition raises a concrete question about which kind of environment a task needs and what survives when it stops.

Different runtime boundaries

Daytona’s isolation guide describes containers with separate namespaces and enforced resource limits. Its Linux VM and Windows classes run full virtual machines with their own kernels. GPU sandboxes use containers with exclusive allocation of their assigned GPU devices. These are different execution boundaries, even though the service groups them under the sandbox label.

Operating system coverage also has a management boundary. The macOS documentation says those environments run on reserved Apple silicon hardware through use.computer. They require that platform’s API and a separate key. Daytona’s SDKs, command line tools and API do not manage them. A team planning one automation system across operating systems needs to account for that separate integration.

Saved files and saved memory are different

The persistence documentation distinguishes files from a running process. Containers retain their filesystem across stopping and starting, but stopping clears memory. Containers cannot pause. Linux VM and Windows sandboxes can pause with memory intact and resume from that state. Stopping a VM still clears its memory, even though its filesystem survives.

Stopped containers keep disk on the runner and continue using disk quota. Stopped VMs offload their files and release that quota, according to Daytona. GPU sandboxes are deleted when stopped. Their results need persistent storage such as a mounted volume if they must outlive the sandbox.

Daytona’s snapshot guide makes the same distinction explicit. A cold snapshot records the filesystem of a stopped sandbox. A hot snapshot includes memory from a running Linux VM or Windows sandbox. Containers support cold snapshots only. The documented hot snapshot request uses the API to include memory, rather than assuming every snapshot operation captures a running application.

The sandbox operations guide describes forks as separate VM sandboxes copied from a parent’s disk and memory. Container users instead create another sandbox from a filesystem snapshot. The guide also says a parent cannot be deleted while active fork children remain. Branching work therefore needs lifecycle tracking as well as a way to create more environments.

Its automatic lifecycle settings also differ by class. Containers stop after 15 minutes of inactivity by default, while VMs that are not ephemeral pause after 60 minutes. Preview traffic does not reset the VM pause timer. A running background process alone does not keep a container alive.

Network rules and preview access

The network limits guide concerns outbound internet access. Tiers 1 and 2 have organization restrictions that individual sandboxes cannot override. Tiers 3 and 4 have internet access by default, with configurable rules that can allow selected IP ranges or domains, or block outbound traffic. Those three settings are mutually exclusive.

On tiers 3 and 4, a custom rule replaces the default policy, and essential services such as package registries get no automatic exception. A restricted build environment therefore needs an explicit inventory of the services it must reach. These settings describe controls, not a guarantee against every unwanted transfer.

Inbound sharing is a separate decision. The preview documentation requires authentication unless a sandbox is made public. It warns that a standard preview token reaches the whole sandbox, including control ports that allow commands and file access. Signed preview URLs are limited to one port, expire and can be revoked. The documentation recommends them for sharing access.

Pausing and resuming keeps an existing standard token, while stopping and starting replaces it. That makes the distinction between pause and stop relevant to credentials as well as memory. A preview link should be assessed by its access scope, not just by the application it appears to display.

The organization is the runtime access boundary

The API key documentation adds an important qualification to resource permissions. It says any valid key for an organization can use the toolbox on that organization’s running sandboxes, including process execution and file access, regardless of the resource permissions selected for the key. Those scopes govern management of resources. They do not create a separate runtime trust boundary for each workload inside an organization.

The distinction between isolation and permitted actions also appears in ByteForward’s coverage of AWS Strands Box, a separate developer preview that adds policy checks around agent operations.

For teams evaluating Daytona, runtime class, state retention, network policy and credential scope belong in the same deployment review. They answer different questions, so confirming one does not settle the others.

The product descriptions above reflect documentation checked on October 21. ByteForward has not tested Daytona’s isolation, recovery behavior or performance. The funding announcement does not establish independent results for any of those properties.

Archival photograph of infrastructure work at NERSC in 2011. Photo by Chiara Coetzee via Wikimedia Commons under CC0 1.0. Illustrative image.