back to microsandbox

compare

microsandboxvsdaytona

pick daytona for its hosted sandbox classes and computer-use APIs. [1][4] pick microsandbox when you need microvms on employee devices, local full snapshots, and a hosted cloud option. [20][21][22]

daytona offers container and VM sandbox classes. VM sandboxes have their own kernel and support memory persistence; container snapshots save filesystem state. [5][6] microsandbox gives each sandbox its own guest kernel through libkrun. [24]

both products offer hosted execution. microsandbox cloud uses the same CLI and SDKs as local execution and is in private beta with access by request. its local runtime also supports full memory snapshots and managed deployment to employee devices. [20][21][22]

microsandbox
local + cloud
daytona
managed sandboxes for agents [1]
hosting model
local runtime · microsandbox cloud (private beta, access by request) [20]
hosted service · own compute with daytona control plane [7]
runs offline
local, after provisioning runtime dependencies and images [23]
hosted service or own compute linked to daytona [7]
isolation
microvm with a separate kernel per sandbox
container class · linux and windows VM classes with their own kernel [5]
languages
rust · typescript · python · go · ruby · cli
python · typescript · ruby · go · java [1]
programming model
embeddable sdk · no service required locally
sdk and api for a managed sandbox service [1]
snapshots
local snapshots save disk state, or disk, memory, and running processes with --full. cloud currently supports disk snapshots from stopped persistent sandboxes and disk restore. [21]
container snapshots save files · VM hot snapshots also save memory [6]
employee-device deployment
administrator settings deployed to employee devices with Jamf or Intune; supported CLI and SDK releases apply managed overrides [22]
own compute connects infrastructure to daytona's control plane [7]
credentials
credentials are destination-bound. the sandbox works with a placeholder; the real value is substituted host-side into supported intercepted outbound requests, only for destinations on your allow-list. an approved destination still receives the real credential and could reflect or misuse it, so scope your allow-lists accordingly.
proxy substitutes secret placeholders in HTTPS headers; configure a host allowlist to restrict destinations [8]
network policy
by default, sandboxes can reach the public internet. private, host-local, link-local, and metadata destinations are blocked. egress can be reduced to an allowlist or disabled entirely. in the cloud, the non-public block cannot be lifted, even by you.
block-all, CIDR or domain allowlists, and outbound proxy controls [5]
computer use
Linux GUI workloads via a documented local VNC setup [9]
computer-use APIs for desktop interaction [4]
license
apache 2.0
agpl-3.0 public source [2]
pricing
free locally · private beta pricing is published
published usage pricing and free credit [3]
pick daytona

choose daytona when

  • you want a managed service with persistent sandboxes and snapshots. [1]
  • you want built-in computer-use APIs for desktop interaction. [4]
  • you need java in the supported sdk surface. [1]
  • you want to connect your compute to daytona's control plane. [7]
pick microsandbox

choose microsandbox when

  • agents must execute on employee devices under administrator-managed settings. [22]
  • every sandbox should start with a separate guest kernel, not a selectable class.
  • you need destination-bound credentials and a host-enforced network floor.
  • you want local full snapshots and branching, plus hosted cloud execution through the same CLI and SDKs. [20][21]

01

does daytona use virtual machines?

yes, for its VM classes. daytona also offers container sandboxes, so the selected class determines the runtime boundary. [5] compare the class you will deploy against microsandbox's per-sandbox guest kernel. [24]

the state model also follows that choice: daytona container snapshots save the filesystem; VM hot snapshots preserve memory too. [6] local microsandbox supports disk and full execution snapshots, while its cloud currently supports disk snapshots from stopped persistent sandboxes. [21]

microsandbox snapshot types

02

cloud infrastructure or employee devices

daytona's bring-your-own-compute offering connects your infrastructure to its control plane. [7] microsandbox's managed device deployment distributes runtime dependencies and administrator settings through Jamf or Intune, so the sandbox itself can execute on the employee's machine. [22]

supported microsandbox releases apply managed overrides above user settings for new backend instances. existing sessions retain their settings, and local administrators can remove the policy or replace the runtime. provision approved packages and images for offline execution. [22][23]

employee-device deploymentmicrosandbox cloud

03

moving a daytona workload

map commands and filesystem operations first, then check dependencies on daytona's computer-use APIs and VM memory persistence. [4][6] microsandbox documents a local Linux VNC desktop, but that is a guest setup rather than a matching computer-use SDK. [9]

a local microsandbox full restore creates a new sandbox with resumed processes. it requires compatible runtime and resource settings, and application connections must reconnect. hosted cloud currently restores disk state only. [21]

local Linux desktop examplecloud compatibility

common questions

is microsandbox a daytona alternative?

yes. both offer cloud sandboxes. microsandbox also runs locally on employee devices, with managed settings and full memory snapshots. [20][21][22]

is daytona open source?

yes. daytona's public repository uses the agpl-3.0 license. [2] microsandbox's local runtime uses apache-2.0.

does daytona use containers or vms?

both. its container class and VM classes have different isolation and persistence properties. linux VM and windows sandboxes have their own kernel. [5]

does daytona support computer use?

yes. daytona supplies APIs for desktop interaction. [4] microsandbox documents a local Linux desktop through VNC, which you configure inside the guest. [9]

which runs locally?

microsandbox runs the microvm locally without a cloud account. [23] daytona's own-compute deployment connects infrastructure to its hosted control plane. [7]

primary sources

  1. [1] daytona sandbox classes and SDKs · last verified 2026-09-24
  2. [2] daytonaio/daytona public repository and agpl-3.0 license · last verified 2026-09-24
  3. [3] daytona published pricing and credits · last verified 2026-09-24
  4. [4] daytona computer-use APIs · last verified 2026-09-24
  5. [5] daytona isolation and network controls by sandbox class · last verified 2026-09-24
  6. [6] daytona filesystem and VM hot snapshots · last verified 2026-09-24
  7. [7] daytona bring-your-own-compute control plane · last verified 2026-09-24
  8. [8] daytona proxy secret substitution and host allowlists · last verified 2026-09-24
  9. [9] microsandbox local Linux desktop with VNC · last verified 2026-09-24
  10. [20] microsandbox cloud availability and backend compatibility · last verified 2026-09-24
  11. [21] microsandbox disk snapshots, full checkpoints, and local branching · last verified 2026-09-24
  12. [22] microsandbox managed deployment with Jamf and Intune · last verified 2026-09-24
  13. [23] microsandbox offline provisioning of runtime dependencies and images · last verified 2026-09-24
  14. [24] microsandbox microVM isolation · last verified 2026-09-24
  15. [25] microsandbox runtime, CLI, images, and language SDKs · last verified 2026-09-24

run it locally.

put the boundary on your own machine before you choose anything else.

run it locally