Daytona vs Unikraft (2026)

An agent in a Daytona sandbox reaches outside systems through what runs inside it. Git operations clone and push repositories, secrets hold credentials and external storage can be mounted. Firewall allow lists decide which hosts the agent may reach. Daytona has no catalog of connectors, OAuth actions or tool gateway of its own. The tools are the customer's code.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Agents' tools run on Unikraft instead of coming from it. MCP servers run as microVMs that wake when an agent calls them, alongside webhook receivers and API gateways, and workloads connect to hyperscaler services such as S3. One customer keeps its credentials outside the VM. Unikraft names no connector catalog, OAuth actions or credential brokering of its own, so the read and write integrations are the customer's code.

Sourceunikraft.com/docs/use-cases/mcp-serversread 2026-09-22

The platform manages sandboxes. It creates and resizes them, applies lifecycle rules and runs warm pools and fleet scaling. It does not sequence, branch, retry or route an agent's steps. In Daytona's guides, agents built in LangGraph, the OpenAI Agents SDK and other frameworks do that, and Daytona has no workflow logic that mixes fixed steps with agent steps.

Sourcedaytona.io/docs/en/sandboxesread 2026-09-22

The platform schedules and scales microVMs, with autoscale, load balancing and forking a live VM for parallel sub agents. It does not sequence, branch, retry or route an agent's steps, and that logic lives in the customer's code. Unikraft offers no workflow logic that mixes deterministic nodes with agent steps. Scheduling across metros decides where compute runs, not how a workflow proceeds.

Sourceunikraft.com/llms-full.txtread 2026-09-22

Events go outward. Webhooks notify the customer's endpoint when sandboxes are created or change state and when snapshots and volumes change. Automated lifecycle rules stop, pause, archive or delete idle sandboxes. An agent's work starts only when the customer's code starts it. There is no schedule, and a stopped sandbox does not wake on an inbound request.

Sourcedaytona.io/docs/en/webhooksread 2026-09-22

Incoming connections wake work without the customer's code starting it. An instance scaled to zero consumes nothing until the next connection arrives. The platform then boots or resumes it in milliseconds and answers, so an MCP server wakes when an agent calls it and a webhook receiver wakes on the incoming event. A tutorial walks through scale to zero triggers. Unikraft names no scheduler.

Sourceunikraft.com/docs/features/scale-to-zeroread 2026-09-22

The agent's code runs on Daytona, but there is no retrieval structure over the customer's content. Volumes and mounted external storage hold files the agent's code reads, and there is no index to query. The language server in a sandbox serves code intelligence for the files there. Nothing in Daytona indexes, refreshes or sets permissions on the customer's sources.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

The platform runs the customer's workloads, including databases and MCP servers, but keeps no retrieval structure over the customer's content for an agent to query. Volumes and databases hosted on it are the customer's own storage. There are no sources that Unikraft indexes, refreshes or permissions.

Sourceunikraft.com/llms-full.txtread 2026-09-22

Persistence is on by default at three layers. The filesystem survives stop, start and archive. On VM sandboxes, memory (running processes and loaded state) survives pause and resume and hot snapshots. Volumes and mounted external storage outlive any one sandbox. Sandboxes can also be forked, and the agent's code reads the restored state to carry on. Paused process state belongs to the machine, so the customer can resume or delete it but cannot review or edit it. There is no separate memory layer that sets what an agent keeps or for how long.

Sourcedaytona.io/docs/en/persistenceread 2026-09-22

A workload's state carries across sessions. Instances snapshot and resume in milliseconds with their state intact, a live VM and its children fork in about ten milliseconds, managed volumes persist data, and paid plans add snapshot history and rollback. The agent's code reads that restored state to carry on.

Volumes are storage the code reads, and restored process state belongs to the machine. The customer can resume, roll back or delete that state but cannot review or edit what it holds. Unikraft offers no separate memory layer for agents. A browser session ROM keeps its own cookies and profile, much like a saved login.

Sourceunikraft.com/docs/features/snapshotsread 2026-09-22

Work in a sandbox has no approval step, consent checkpoint or escalation to a person. VNC, a web terminal and SSH let a person watch a sandbox and step in by hand. A firewall on each sandbox (allow lists or block all, with organization tiers that sandbox settings cannot override) restricts what an agent's code can reach. Nothing holds an agent's action for a person to review.

Sourcedaytona.io/docs/en/network-limitsread 2026-09-22

Unikraft names no approval step, consent checkpoint or escalation to a person for the work it runs, and no place to insert one. The network shield and relay, an Enterprise feature, routes an instance's traffic through a relay VM, and delete locks stop instances being removed. The developer configures both for isolation and protection, and neither has a person review an agent's action.

Sourceunikraft.com/docs/features/network-shieldread 2026-09-22

Organizations sign in through OpenID Connect providers such as Google Workspace, Microsoft Entra ID and Okta, with provisioning and membership handled at sign in on the Enterprise plan. Collaborative organizations have owner and member roles plus granular assignments by resource, such as SSO Admin and access to the audit log.

API keys carry permissions and scopes, with managed child keys. An audit log covers user and system activity, and each sandbox has firewall allow lists or block all. Daytona says it meets HIPAA, SOC 2 and GDPR standards and has a Trust Center, but it names no report type or auditor.

Sourcedaytona.io/docs/en/ssoread 2026-09-22

The company holds SOC 2 Type II against the Security criteria and is HIPAA compliant, with BAAs available. An independent penetration test by DEFION Security found no exploitable cross VM, hypervisor, filesystem or host agent issues. Alongside these, every workload is its own Firecracker based microVM with per tenant filesystem boundaries, delete locks protect instances from removal, and on Enterprise a network shield and relay route an instance's traffic through a relay VM.

Unikraft names no SSO, roles or identity provider support.

Sourceunikraft.com/llms-full.txtread 2026-09-22

Each step an agent takes in the sandbox is recorded. SDK tracing instruments every Daytona API operation and SDK call from the customer's application, such as each command run, file written or process started. Sandbox telemetry collects traces, logs and metrics from inside the sandbox.

Both export over OpenTelemetry to the customer's own collector, and Daytona keeps sandbox telemetry for three days. A separate audit log records user and system activity with the user, action and time, and logs can be streamed. The model's reasoning runs outside Daytona. Audit export is not available yet, and Daytona says it is coming soon.

Sourcedaytona.io/docs/en/observability/otel-collectionread 2026-09-22

Logs and metrics follow the instance, not the agent. Every user gets full stdout and stderr logs, paying customers get Prometheus metrics, and a metrics API reports CPU time, memory, network I/O, connection counts and scale to zero wake latency per instance. The metrics export to monitoring systems. Inspecting prompts, tool calls, retrieved knowledge and outputs step by step is left to the customer's own code. Unikraft names no audit log separate from the runtime logs and no retention by plan.

Sourceunikraft.com/docs/platform/metricsread 2026-09-22

Sandboxes run in two shared regions, the United States and Europe, chosen per sandbox. Under Bring Your Own Compute, an organization instead creates custom regions and attaches its own runner nodes, with an optional proxy and snapshot manager for each region, for control over data locality and compliance.

Daytona's control plane manages them, and BYOC is sold on the Enterprise plan. The platform sold today cannot be self hosted from open source. Core development has moved to a private codebase, and the public github.com/daytonaio/daytona repository gets no further updates. Its last release, v0.190.0, stays public under AGPL 3.0.

Sourcedaytona.io/docs/en/bring-your-own-computeread 2026-09-22

Customers choose the named metros where Unikraft Cloud runs. Dallas, Frankfurt, San Francisco, Singapore and Washington DC are the defaults, and the list is set per account. Deployment can be hosted, dedicated hosted, on premises or BYOC, on bare metal or on AWS EC2, GCP Compute Engine or Azure VMs. A Kubernetes integration adds Unikraft Cloud as a node in EKS, GKE, AKS or the customer's own cluster.

Sourceunikraft.com/docs/platform/metrosread 2026-09-22

Ready made starting points for running agents include default sandbox snapshots in several sizes, a Declarative Builder for images and an agent skill for coding agents. More than forty guides run coding agents (Claude Code, Codex, Devin, Gemini CLI, OpenClaw, OpenCode), as well as framework agents and reinforcement learning setups, in sandboxes, and a reference implementation runs Cursor's Cloud Agents on self hosted Daytona sandboxes. Developers build from these environments and walkthroughs. There is no browsable catalog of agents a customer can adopt.

Sourcedaytona.io/docs/en/agent-skillsread 2026-10-23

Templates here are snapshots of the customer's own warmed up workload that new instances boot from, not ready made starting points from Unikraft. Unikraft covers patterns for sandboxes, headless browsers, MCP servers and remote desktops, but ships no working agents, production ready templates or role specific agents for a customer to adopt.

Sourceunikraft.com/docs/features/on-demand-templatesread 2026-09-22

The customer chooses the model. Guides run agents on Claude, OpenAI Codex and the Agents SDK, Gemini, Kimi and AWS Kiro, and on open models through OpenCode and other frameworks. GPU sandboxes serve the customer's own LLMs with vLLM or SGLang. Daytona imposes no model, and customers bring their own providers and keys, with guides on setting them up.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Any Dockerfile workload runs here, and nothing in the platform is specific to language models. There is no model selection, routing, provider keys or guidance for connecting the customer's own models. GPUs appear only for rendering in headful browsers. The platform imposes no model of its own either.

Sourceunikraft.com/llms-full.txtread 2026-09-22

Outside callers reach Daytona through SDKs in five languages (Python, TypeScript, Ruby, Go and Java), a REST API with published OpenAPI specifications, and a CLI. The specifications cover the Daytona API, the Toolbox API inside the sandbox and an Analytics API. An MCP server lets Claude, Cursor and Windsurf manage sandboxes, and an agent skill serves coding agents.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

From outside, a platform REST API drives Unikraft Cloud, covering instances, templates, volumes, services and metrics. The unikraft CLI adds a raw API passthrough, and a Kraftfile specification and Kubernetes and Karpenter integrations round it out. Unikraft names no SDK or MCP server of its own. Some newer features, such as plugins and the network shield, are available only through the API for now.

Sourceunikraft.com/docs/llms.txtread 2026-09-22

Evaluations and reinforcement learning run on Daytona, but it does not score them. Its guides run training with HUD, TRL, veRL and OpenEnv in sandboxes, along with a benchmark agent across several languages. The datasets, reward functions and scoring belong to those frameworks. Daytona offers no fixtures, scoring or quality gates for a customer's agent workflows, and no way to compare agent runs.

Sourcedaytona.io/docs/llms.txtread 2026-09-22

Tests get somewhere to run, but Unikraft does not test agents. Forking and the build and test environments pattern give the customer disposable, parallel VMs. The platform has no fixtures, scoring, quality gates or comparison of agent runs.

Sourceunikraft.com/docs/llms.txtread 2026-09-22

The Computer Use API gives an agent programmatic control of a desktop in the sandbox, from mouse and keyboard to screenshots, screen recording and display operations, on Linux and Windows. VNC lets a person watch or take over. The desktop runs remotely on Daytona's infrastructure. macOS sandboxes run on Mac hardware reserved for the customer through use.computer, with their own API key, and the Daytona SDKs, CLI and API do not manage them.

Sourcedaytona.io/docs/en/computer-useread 2026-10-23

Browser and desktop agents get their machines here. Every browser session can run in its own disposable headless or headful microVM with GPU rendering, booted from a snapshotted template, and whole desktop sessions snapshot after login and resume on connect. Browser agent companies run on it. The platform works with any browser, so the customer brings the browser and drives it with its own tooling. Unikraft offers no API of its own for screenshots, clicks or typing. It supplies the environment for operating web interfaces and desktops, and the customer supplies the control.

Sourceunikraft.com/docs/use-cases/headless-browsersread 2026-09-22