# Inside Ivan Burazin's Rebuild of Daytona

> Daytona's founder turned a developer-workspace company into an agent-computing platform. Its funding, product docs and security advisories show what buyers can test, and what remains a company claim.

- Published: 2026-10-26
- Author: Gene Dai
- Canonical: [https://digidai.github.io/2026/10/26/ivan-burazin-daytona-agent-sandbox-pivot/](https://digidai.github.io/2026/10/26/ivan-burazin-daytona-agent-sandbox-pivot/)
- Topics: Ivan Burazin, Daytona, AI Agents, Cloud Infrastructure, Security, Deep Investigation

---

![An illustrated computer opens into a grid of separate agent work chambers under the words The Agent Computer.](/images/articles/ivan-burazin-daytona-agent-sandbox-pivot/cover-v1.jpg)

_AI-generated editorial illustration._

Ivan Burazin described a startling handoff in an
[October 20 interview with Fortune](https://fortune.com/2026/10/20/daytona-startup-building-the-agentic-cloud-valued-at-1-billion-in-latest-funding-round/).
Daytona, the company he had co-founded to manage development environments for people, had enterprise customers. The
founders then chose to rebuild around computers that software agents could use. In his account, they effectively
surrendered those customers to competitors and relaunched with about three months of revenue left in the bank. The
interview records Burazin's version of the decision; it does not disclose the company's books or establish the exact
date of the last customer handoff.

Six days before this article, Burazin
[announced](https://www.daytona.io/dotfiles/daytona-raises-60m-series-b-to-build-the-agent-cloud) a
$60 million Series B at a reported $1 billion valuation.
[TechCrunch's October 23 report](https://techcrunch.com/2026/10/23/agent-cloud-startup-daytona-hits-1b-valuation-backed-by-firstmark-and-a-whos-who-of-angels/)
named FirstMark Growth as lead investor and put Daytona's cumulative funding at $91 million. The financing shows that
investors accepted the change in direction. Users still have to find out how the sandboxes perform on their own work.

The harder part of Burazin's bet lies underneath the valuation. An agent that writes code, checks a page or manipulates
a desktop needs a place to execute instructions. That place may have to appear quickly, remember the right state,
isolate untrusted code and stop consuming expensive resources when the job is over. Daytona offers several kinds of that
place. Its current documentation distinguishes a default Linux container from separate virtual-machine products, while
documentation for a new Firecracker-based architecture is explicitly labeled alpha. Those are materially different
operating and security choices.

Burazin has made a claim about the future size of the opportunity: a computer for every agent. This profile asks a
narrower question. What did he actually rebuild, and what would a technical buyer need to verify before giving that
computer a production workload?

## From Codeanywhere to the first Daytona

The first Daytona was not conceived as an agent cloud. In
[November 2023, TechCrunch described](https://techcrunch.com/2023/11/06/daytona-wants-to-be-an-enterprise-grade-github-codespaces/)
a self-hostable development-environment manager for companies that wanted standardized workspaces without handing
control of their code and setup to someone else's cloud. Burazin, chief architect Goran Draganić and CTO Vedran Jukić
had experience with a related problem. Burazin and Jukić had co-founded Codeanywhere, a browser-based development
environment. Daytona's proposed user was a human developer opening a repository and expecting the right dependencies,
tools and settings to be ready.

For that developer, the pain is intermittent but familiar. A project can work on one machine and fail on another because
the environment has drifted. A new employee can spend days arranging tools before writing useful code. An enterprise may
want the setup to run inside its own infrastructure. TechCrunch's 2023 account placed Daytona against GitHub Codespaces
and other cloud development tools. The competitive promise was less setup work with more control over where workspaces
lived.

Daytona's
[June 2024 funding announcement](https://www.daytona.io/dotfiles/daytona-secures-5m-to-simplify-development-environments)
still spoke this language. It called the product a self-hosted development environment manager, announced $5 million in
new financing, and emphasized the company's Apache-2.0 open-source release earlier that year. The company said annual
recurring revenue had nearly doubled in six months. It did not publish the starting figure. A surge of GitHub stars
showed developer attention; it said little about retained enterprise use. The old product had a commercial life of its
own, however brief, before the agent pivot.

Burazin's professional route helps explain why he recognized the workspace as a product. A
[2023 Daytona profile](https://www.daytona.io/dotfiles/meet-ivan-burazin-our-ceo-and-dev-empowerment-champion) traces
his work from Codeanywhere to the Shift developer conference and a developer-experience role at Infobip. That is the
company's own biography, useful for role and chronology but not a source of private motives. A person who has sold tools
to developers can see why reproducible computers are valuable. It does not follow that the same sales motion or product
architecture will serve an automated fleet.

Burazin gave a more specific account of the cost of moving. In
[Cristian Dina's October interview for The Next Web](https://thenextweb.com/news/ivan-burazin-daytona-ai-agent-sandboxes-tnw-podcast),
he said the earlier enterprise product brought in a few hundred thousand dollars a year before the founders went back to
zero. The number is a founder recollection, not an audited financial statement. Yet the story poses a real decision:
keep a small, functioning business for people, or spend limited time building for a workload that might grow far faster
and arrive at irregular intervals.

The change was in the buyer's operating unit. One developer might keep a remote workspace for a day, a week or longer.
An agent system could start many short jobs, branch from a known state, fail, retry and discard its workspace without a
person watching each one. The account that pays may be a platform team rather than the person using a coding tool.
Isolation becomes a repeated, automated event. So does billing. A convenient developer machine is no longer the complete
product; the customer also needs lifecycle controls for a fleet of machines.

FirstMark partner Matt Turck
[led Daytona's $24 million Series A in February 2026](https://firstmark.com/story/announcing-our-investment-in-daytona)
and joined its board. His investment note argues that agents need instantly provisioned, isolated computers in large
numbers. Turck was describing the market he wanted Daytona to build. His commitment put board-level money behind the
agent-execution platform rather than another iteration of the developer-workspace sale.

## A computer that can be thrown away, then resumed

Daytona's agent computer is not one machine type. The current
[v0.226 sandbox documentation](https://www.daytona.io/docs/en/sandboxes/) says Linux containers are the default. It also
lists Linux VM, Windows VM, macOS on Apple silicon, and GPU sandboxes. Those options answer different jobs. A
code-generation agent may need a quick Linux process. An agent testing a native Windows application needs Windows. A
graphics workflow may need a GPU. The company's October financing post
[presents all four](https://www.daytona.io/dotfiles/daytona-raises-60m-series-b-to-build-the-agent-cloud) as part of one
platform. A prospective customer would have to match the advertised class to its region, quota and invoice rather than
take the product menu as a deployment plan.

The common requirement is that an environment can carry work across steps. The
[v0 persistence guide](https://www.daytona.io/docs/en/persistence/) says files, installed packages and repositories
survive a stop/start cycle by default. It draws an important distinction between filesystem and memory. A stopped
container retains files but loses its running processes and memory. A paused VM can preserve memory state for resume. An
agent that needs a Python package installed for its next task may only need persistent files. An agent that needs an
open application session or running process may need the stronger memory guarantee and the VM workflow that supports it.

The word "persistent" can conceal three different commitments. It can mean a working directory survives. It can mean a
process resumes at the instruction where it paused. It can mean a volume outlives any one sandbox. Each creates a
different recovery story after an interruption. A platform choosing Daytona would have to say which state is part of a
user-visible promise. If an agent writes a draft and its container stops, the draft may remain. If its work depends on
unsaved application memory, the result may not.

Daytona offers snapshots and [warm pools](https://www.daytona.io/docs/en/warm-pools/) to shorten the time between a
request and useful work. A snapshot captures a prepared filesystem and can seed new environments. A warm pool holds
pre-created running sandboxes for a matching snapshot and region so a create request can claim one immediately. That is
a practical approach to a queue of similar tasks, but the warm capacity has already been provisioned. Its idle resource
cost belongs in any end-to-end price comparison.

The
[OpenAI Agents API documentation](https://developers.openai.com/api/docs/guides/agents-api/environments/providers/daytona)
now includes a Daytona environment-provider guide. That is independent evidence of an integration path, with
instructions for both application-managed and webhook-managed provisioning. Its operational warning is revealing: an
executor's long outbound connection may not register as sandbox activity, so the guide tells operators to disable
automatic stopping for the active session and set a lifetime limit. A platform can provide the machine, but the
application still has to coordinate the machine's lifecycle with the agent's actual work. A provider guide does not show
how many paying customers use that path.

In the October interviews, Burazin said Daytona had added Windows and GPU environments after seeing customer needs.
[The Next Web's account](https://thenextweb.com/news/ivan-burazin-daytona-ai-agent-sandboxes-tnw-podcast) attributes
examples such as AutoCAD and Blender work to him. The distinction is important: the published interview verifies that he
made the claim; it does not publish a reproducible workflow or customer result for each application. For a buyer, a
successful demo would need to include a realistic file, the required software license, an agent's failure and retry
path, and a bill after the sandbox is stopped.

![An illustrated set of code sheets passes through two separate containment options toward a three-needle measurement dial.](/images/articles/ivan-burazin-daytona-agent-sandbox-pivot/isolation-and-meter-v1.jpg)

_AI-generated editorial illustration. The two chambers depict alternative isolation choices, not a benchmark or a claim
that all Daytona sandboxes use the same runtime._

## From creation to first useful action

Burazin told
[Fortune](https://fortune.com/2026/10/20/daytona-startup-building-the-agentic-cloud-valued-at-1-billion-in-latest-funding-round/)
that Daytona could configure a sandbox in 60 milliseconds by placing prepared snapshots on server drives, then attaching
compute and memory when one is needed. Daytona's current docs advertise rapid container creation, and its warm-pool
guide explains how an already running environment can be handed to a requester. That makes the mechanism plausible. It
does not establish that every class, region, image and workload starts a useful agent in 60 milliseconds.

Start a timer when an application requests a sandbox. A vendor may start its own timer only after that request reaches
its control plane, perhaps after a warm machine has already been allocated. One timer may stop when a sandbox object
exists; the application keeps waiting for its executable to connect and its first action to finish. Each number can be
accurate. Only one describes the user's wait. A buyer needs the distribution across many starts, including the slow tail
and failed starts, for the specific environment it intends to run.

An agent task also contains more than startup. The system may fetch a repository, install a package, authenticate a
tool, load a browser, run a model step, inspect the output and retry. A fast empty sandbox saves little if the
repository or browser dominates the path. A cached snapshot can help, but now the organization must keep that snapshot
current and safe. An outdated dependency or leaked credential carried in a snapshot can turn a speed optimization into a
repeated defect.

Fortune reported that conventional virtual-machine provisioning at large cloud providers can take tens of seconds or
minutes; that broad statement does not set a like-for-like comparison against every hyperscaler service. A fair trial
would put a Daytona warm sandbox against another prepared environment, and a fresh Daytona VM against a fresh VM
elsewhere. It would time the complete task under equivalent isolation and resource constraints.

Burazin also argues that agent workloads will pressure CPU capacity, not just the GPUs that run models. In the
[Fortune interview](https://fortune.com/2026/10/20/daytona-startup-building-the-agentic-cloud-valued-at-1-billion-in-latest-funding-round/),
he forecast a CPU crunch. There is a sensible physical reason to watch CPUs: browsers, operating systems, compilers and
many business applications run on them. His forecast still depends on how many tasks require separate environments, how
long each environment stays active, how much work can be packed safely together and how much use shifts to serverless or
existing infrastructure. A projection about the addressable market is not a capacity measurement for Daytona.

The platform's [scale documentation](https://www.daytona.io/docs/en/scale/) frames the sandbox as a long-lived computer
rather than a single request. That matters to utilization. Keeping a machine alive can avoid repeated setup, and it can
also reserve capacity during gaps in work. An agent that receives one task every hour might look efficient on a per-task
startup chart while consuming idle resources between tasks. A team evaluating Daytona should log task arrival, start,
first useful action, active CPU, stopped time and retained disk separately. The shape of those measurements will decide
whether fast startup improves the economics of its particular agent.

## Which isolation boundary does a buyer get?

One sentence in Daytona's current documentation changes how to read the company's security story:
["Sandboxes run as Linux containers by default."](https://www.daytona.io/docs/en/sandboxes/) Linux VM and Windows are
offered as separate classes. The same overview also describes every sandbox as having a dedicated kernel. Daytona's more
detailed [v0 isolation table](https://www.daytona.io/docs/en/isolation/) clarifies that the container class uses
dedicated namespaces and resource limits while the VM classes have their own kernels. That difference deserves a plain
answer in a purchase discussion. A container normally shares a host kernel while separating processes, filesystems and
namespaces; a VM has a guest kernel behind a hypervisor boundary. Neither choice substitutes for network policy,
credential scope or correct application design.

The company's [v2 isolation documentation](https://www.daytona.io/docs/en/v2/isolation/) describes each sandbox as a
Firecracker microVM with its own kernel and network stack. The same page prominently says v2 is in alpha and directs
readers to v0 for the latest release. Treating the v2 description as a guarantee for the default v0 container would
erase the version boundary in the company's own documentation. It would also conceal a procurement question: which
version and sandbox class will the buyer actually deploy when the contract begins?

The v0 [isolation guide](https://www.daytona.io/docs/en/isolation/) says code in one sandbox cannot read another's
filesystem or memory and explains runtime, network and organization boundaries. That is the provider's statement of its
controls. A technical evaluation should test a scoped workload against the precise runtime and threat model, then
examine independent assessments, incident history, audit logs and contractual commitments. The word "isolated" names an
intended property. The selected runtime, policy and tests show what stands behind it.

Network reachability is another boundary. The [v2 alpha guide](https://www.daytona.io/docs/en/v2/isolation/) says
outbound internet access is open by default but can be restricted with a network policy; incoming access is closed by
default until an endpoint is exposed. The [v0 isolation guide](https://www.daytona.io/docs/en/isolation/) describes a
different tier-dependent default: outbound access is open at higher tiers and restricted at lower tiers, with
sandbox-level block and allow-list controls. A trial on v0 must check the account's actual tier and explicit policy. An
agent allowed to read an untrusted page and contact arbitrary destinations faces a different risk from one restricted to
named services. Runtime isolation alone cannot stop an authorized process from sending data through an allowed
connection.

That separation has become more than a theoretical concern. In an
[October 23 report on its own frontier-model training environment](https://openai.com/index/securing-our-frontier-model-training-environment/),
OpenAI described red-team agents finding escape paths and communication channels across environments intended to be
separate. Those tests occurred in OpenAI's systems, not Daytona's; they do not establish a Daytona flaw. They show why a
buyer should ask about the whole containment perimeter rather than one sandbox primitive. The surrounding services,
caches, shared hardware, credentials and outbound paths can matter after the runtime boundary is drawn.

Daytona's documentation offers a way to make the question concrete. An evaluator can define a low-sensitivity task,
provision the actual class and version, restrict it to required destinations, issue a short-lived scoped credential, and
record every file and network action. Then it can deliberately stop, resume, fork or delete the environment and verify
which state persists. It should repeat the trial with an error and with an untrusted input. That is a bounded validation
plan, not a claim that any particular attack will succeed.

## Two advisories, then a closed-source decision

Burazin's current product sells containment, which makes Daytona's 2026 security disclosures part of the profile rather
than a footnote. On April 9, a researcher reported that
[a Daytona API credential could reach a sandbox process](https://www.daytona.io/dotfiles/updates/security-advisory-api-credential-exposure-in-sandboxes).
In the company's account, its default snapshot allowed passwordless sudo. Someone with shell access to that sandbox
could read the credential from memory and act with the launching account's permissions. The issue did not apply to
custom snapshots without sudo or root. Daytona said it patched all regions the same day by stripping the authorization
header at the proxy before the request reached the sandbox.

The advisory matters because it crosses two boundaries that buyers may mentally combine. A sandbox can separate a
process from its host and still be given a credential that opens other resources in the same organization. Daytona said
a stolen credential could reach other sandboxes and API functions allowed to that account. It advised affected users to
rotate keys and inspect logs. The company found no evidence of exploitation, while explicitly saying ordinary-looking
API traffic meant it could not prove none occurred. Those statements should be kept together. Calling the matter a
confirmed breach would outrun the record; calling it harmless would ignore the stated rotation advice.

Later that month, Daytona published an
[advisory on CVE-2026-31431, nicknamed Copy Fail](https://www.daytona.io/dotfiles/updates/security-update-cve-2026-31431-copy-fail).
The underlying Linux-kernel flaw could allow a controlled change to cached file contents in memory. Daytona said the
primitive had been reachable inside a sandbox on affected runners and might make corrupted cached content visible to
another tenant on a shared host. The company reported no observed exploitation or host escape and said it remediated
remaining runners within 12 hours of public disclosure. That is a company assessment and remediation account, not an
independent audit of the fleet.

Together, the two advisories illustrate different failure modes. One concerned a credential that should not have been
exposed to a process with shell access. The other concerned a host-kernel primitive in an affected runtime. Neither can
be reduced to a generic score called "sandbox security." They require separate tests, patch controls and
incident-response paths. A buyer who only asks whether Daytona has a sandbox may miss the specific question of which
credential the sandbox can see and which kernel boundary the selected class uses.

On June 11, Daytona [announced](https://www.daytona.io/dotfiles/updates/daytona-is-going-closed-source) that its
production codebase would move from open to closed source. In 2024, the company had
[promoted its Apache-2.0 release](https://www.daytona.io/dotfiles/daytona-secures-5m-to-simplify-development-environments)
as a way to make development environments accessible. The June post said the existing public repository would remain
available without continued maintenance, while SDKs and documentation would continue separately. The company argued that
AI-assisted vulnerability discovery had changed the risk of exposing its isolation implementation. That is Daytona's
rationale; public materials here do not demonstrate that closing the code made its product safer than an alternative
review model.

The decision changes what customers can inspect. The old public repository offered outsiders a way to read code, even if
no one could guarantee they had found every flaw. Closing the production repository takes that direct view away from
attackers and unaffiliated reviewers alike. The practical substitute is not an assertion of secrecy. It is a documented
security architecture, external testing with meaningful scope, fast disclosure, customer-visible logs and clear
responsibility for remediation. Daytona's April advisories provide useful incident detail. Future disclosures will show
whether that practice survives the commercial pressure to sell a reassuring boundary.

## Valuation meets the resource bill

The $1 billion figure in October is an investor valuation attached to a $60 million financing, not an audited measure of
the agent-computing market. Daytona
[said in its announcement](https://www.daytona.io/dotfiles/daytona-raises-60m-series-b-to-build-the-agent-cloud) that
revenue had grown roughly 25 times since January and that average monthly net revenue retention was around 135%. Burazin
gave Fortune a similar revenue-run-rate claim and described monthly growth of about 50.9%. The public accounts do not
give starting revenue, absolute current revenue, cohort definitions or a full reconciliation of those measures. A small
base can grow by a large multiple. Retention above 100% suggests expansion within a defined customer set, but the
definition and duration matter.

The company and Fortune also named customers.
[Fortune wrote](https://fortune.com/2026/10/20/daytona-startup-building-the-agentic-cloud-valued-at-1-billion-in-latest-funding-round/)
that Daytona said Snorkel had provisioned more than one million sandboxes. A count of provisioned environments is a
workload signal. It does not say how many were concurrent, how long they ran, which product class they used, how many
completed useful work, or what Snorkel paid. Daytona's
[October post](https://www.daytona.io/dotfiles/daytona-raises-60m-series-b-to-build-the-agent-cloud) lists Meta, Cohere,
Handshake, Snorkel and other companies across model development and applications. Those are vendor-reported customer
names; their presence does not disclose production scope or economic returns. The next useful evidence would be a
customer-defined task cohort with completion, failure, latency and spend measurements.

A customer sees another clock: the meter on each sandbox. Daytona's
[v0 billing guide](https://www.daytona.io/docs/billing) says a started sandbox incurs charges for reserved CPU, RAM and
disk. Stopped containers and paused VMs stop CPU and RAM charges but continue to incur disk charges. Archived containers
do not incur those resource charges; snapshots retained separately may still cost storage. The policy is more precise
than the phrase "pay for what you use," because a reservation can be billable while a process is doing little useful
work.

The public [Daytona pricing page](https://www.daytona.io/) displayed hourly rates of $0.0504 per vCPU, $0.0162 per GiB
of memory and $0.000108 per GiB of storage when checked for this article on October 26. That is a dated rate-card
snapshot, not a quote for every region, class, customer contract or future month. Windows, GPUs and particular
configurations can change the price. The v2 alpha [billing model](https://www.daytona.io/docs/en/v2/billing/) describes
different metering rules and modifiers. It should not be silently substituted for the latest v0 product in a cost
estimate.

The v0 documentation lists a default sandbox shape of
[one vCPU, one GiB of memory and three GiB of disk](https://www.daytona.io/docs/en/sandboxes/). At the displayed rates,
keeping that shape started for 24 hours would sum to about
$1.61 in the three listed resource charges before any other fee or discount. One thousand such environments held for the same full day would put those listed charges near $1,606.
This is arithmetic on a public rate card, not a Daytona invoice or a realistic workload forecast. Most agent systems
would vary run time, class, warm capacity, discounts and retention; the calculation simply shows why an idle minute
multiplied across a fleet belongs in the design review.

An application team can make the expense legible without taking a vendor's market forecast on faith. It can calculate
the cost of a completed task: sandbox creation and warm-pool reservation; active CPU and memory; retained disk and
snapshots; network and software licenses where applicable; failed and retried runs; and the engineering time spent
managing policies. That unit is more useful than price per sandbox-minute alone. It also reveals whether a choice that
improves latency increases idle capacity or whether a stronger isolation class changes the budget enough to alter the
workflow.

Daytona competes with other execution layers. [E2B](https://e2b.dev/) markets an agent sandbox platform around a microVM
runtime. [Fly's Sprites](https://fly.io/sprites/) offers persistent Linux computers and checkpointing. Hyperscalers have
long offered compute and are expanding AI infrastructure. Those product pages describe the alternatives; none supplies a
shared benchmark. A useful comparison holds task, region, runtime boundary, prewarming, state retention and support
constant, then counts total cost. The winner for a short code-evaluation job may differ from the winner for a persistent
desktop agent. Burazin's product thesis is strongest when framed as a measurable workload fit, not as the assertion that
every agent needs one identical machine.

## One contained job at a time

The October financing sits beside a product that has changed substantially since 2023. Burazin chose an agent platform
over a small enterprise-workspace business, as he described to Fortune and The Next Web. Daytona shipped several sandbox
classes, documented how they retain state, and disclosed two security issues with specific remediation accounts. A
public tally of production workloads, an end-to-end latency distribution, and an independently scoped assessment of the
current default runtime would let outsiders judge more of the rebuild.

An agent-cloud buyer could ask for a narrow proof rather than a grand projection. Choose one real workload whose inputs
can be shared safely. Record a week of task arrivals and outcomes. Run it on the current Daytona class selected for
production, with network egress and credentials limited to that task. Measure creation, first useful action, completion,
retries, stopped and paused time, and the retained storage bill. Verify the recovery path after a failed run. Ask which
findings from the April advisories would have been visible in the customer's logs and which independent assessment
covers the current runtime. Then compare those results with one alternative under the same constraints.

The earlier workspace promised that a programmer could sit down and start working. An agent environment promises useful
work when nobody is sitting there to watch. In that absence, defaults become product decisions. A process may stay alive
after the person who requested it has left. A key may reach farther than the task. A file can survive while the
application that held it in memory is gone. The meter keeps time through every one of those states.

Daytona's valuation puts a large number beside the company's name. The smaller number is harder to produce: the cost of
one completed job that stayed within its intended boundary, on the runtime the customer actually received. That result
will tell more about Burazin's rebuild than the financing headline.

## Continue reading

- [One Employer Reached 141 AI Solutions. Another Kept Three.](https://digidai.github.io/2026/09/10/ai-sandbox-141-solutions-hidden-work/): Examine the operational work hidden behind a growing catalog of AI sandbox products.
- [When Digital Workers Keep Their Old Badges](https://digidai.github.io/2026/04/29/agent-access-drift-hr-ai-data-security/): See how an agent can retain more access than the task requires.
- [AI Agents Can Skip the UI, Not the SaaS Bill](https://digidai.github.io/2026/05/15/agent-action-tax-saas-workflow-pricing/): Compare the cost of agent actions with the cost of model responses.
- [Matt Garman's AWS AI Infrastructure Strategy](https://digidai.github.io/2025/11/15/matt-garman-aws-ceo-ai-infrastructure-race-deep-analysis/): Follow the hyperscaler response to new AI infrastructure workloads.