Daytona
containercloud-platformA dev-environment sandbox platform whose self-hosted default was measured as a privileged runc container, despite 'dedicated kernel' marketing.
Two sources disagree and we lead with the measurement. Daytona's docs describe a Sysbox default with an optional Kata runtime; the June 2026 study verified the actual default install path invoking runc with Privileged:true, citing apps/runner/pkg/docker/container_configs.go:134. That study tested the self-hosted distribution via Docker Compose around 2026-05-20; the hosted product may differ and has not been independently measured. Daytona's core went private in June 2026, so the cited file may no longer be public.
Daytona provides sandboxes for AI agents and dev environments, marketed with a 'dedicated kernel' for every sandbox. A June 2026 comparative study measured the self-hosted default and found something weaker than the docs describe: the default install path runs a plain runc container (runc 1.3.5 via Docker-CE 29.x and containerd), and the runner hardcodes Privileged:true, which disables Docker's default seccomp profile, AppArmor enforcement, and user-namespace isolation. The consequences are measurable: the largest /dev exposure in that study (268 entries), ten host identifiers readable from inside the sandbox (CPU brand, RAM, kernel version, BIOS details, disk serials), and five of seven standard hardening layers left not merely unset but unreachable by the operator. So the honest reading is not 'a hardened container sold as a VM', it is a privileged container sold as a VM. is tier-gated by allowlist.
Strengths
- Fast dev-environment sandboxes with a tier-gated egress allowlist
- The engine it ships is current: the default Docker Compose path pulls Docker-CE 29.x with runc 1.3.5, carrying every in-window CVE fix
- A vendor-documented Kata/Linux-VM runtime offers a real hardware boundary, if you opt into it
Limitations
- The measured self-hosted default is a privileged runc container, not the marketed dedicated kernel
- Privileged:true closes off the hardening an operator would normally add: seccomp, AppArmor, user-ns, no_new_privs, and pids-max were all unreachable
- Shared kernel, and runc carried four escape-class CVEs in the study's 24-month window
- Ten host identifiers leak into the sandbox, the worst leakage result in that study
- Core went private in June 2026, so the default is harder to re-verify than it was
Files & editor
desktop-remoteA dev-environment platform: connect your desktop editor (VS Code / JetBrains) to the remote workspace, or edit inside with a terminal editor.
How you get your project into the environment and edit it. Shared-kernel routes bind-mount host files for your desktop editor; own-kernel routes keep files in the guest, so a desktop editor attaches over remote, or you edit inside. Mounts and remote editing.
Secrets
secrets: managedWorkspace secrets are injected as environment variables.
The realistic agent threat is exfiltration, not a kernel escape. Keeping credentials out of the code's reach is what defends against a prompt-injected agent stealing your keys. Keeping keys out of the blast radius.