# daytona snapshots

Someone asked me what a snapshot is, and I realized the answer depends heavily on which infrastructure product you are talking about.

In Daytona, a snapshot usually means a reusable sandbox template created from a Docker or OCI-compatible image. In Freestyle, a snapshot means an immutable saved state of an entire VM: filesystem, memory, and CPU registers.

Those sound similar until you try to use them for agents.

If your agent only needs a reproducible environment with Python, Node, package caches, and some files installed, a Docker/OCI-style snapshot is useful. If your agent needs to preserve a running dev server, a browser session, a database process, open sockets, shell history, in-memory language state, or a half-finished multi-step task, you need a full-machine snapshot.

That is the difference.

What a Daytona snapshot is

According to the Daytona snapshot docs, Daytona snapshots are sandbox templates created from Docker or OCI-compatible images. Sandboxes can use default snapshots or custom snapshots so that new sandboxes start with consistent dependencies, settings, and resources.

You can create Daytona snapshots from:

• public container images
• local images
• private registry images
• Daytona's declarative builder
• GPU snapshots for GPU sandboxes

The snapshot creation flow asks for an image name, tag or digest, optional entrypoint, and resource settings. Daytona also documents default snapshots such as daytona-small, daytona-medium, and daytona-large, which are based on the daytonaio/sandbox:<version> image.

That is a good primitive. It is basically the same mental model as "make me a prebuilt environment from this container image." It gives you repeatability. It gives you faster setup than installing everything from scratch. It lets teams standardize a sandbox base.

It is not the same thing as a full VM snapshot.

The important detail is that the main Daytona snapshot abstraction is image/template-shaped. It captures the base operating environment: base OS, installed packages, dependencies, configuration, and resources. A new sandbox starts from that environment.

Daytona also has a newer Create Snapshot from Sandbox API that its docs mark experimental. That feature is closer to what people usually mean by checkpointing a live environment: it captures a point-in-time copy of a sandbox's filesystem and memory so it can be reused as a base for new sandboxes.

So the fair description is:

Daytona's stable, central snapshot model is a Docker/OCI-based sandbox template. Daytona's live sandbox snapshot API exists in the docs, but is marked experimental as of May 20, 2026.

That distinction matters when you are comparing it to Freestyle.

What a Freestyle snapshot is

In Freestyle, a snapshot is a saved state of a VM.

The Freestyle VM lifecycle docs define snapshots as capturing the entire VM state: memory, disk, and CPU registers. The Specs and Snapshots docs say the same thing and add the key operational detail: running or suspended VMs create live snapshots that resume instantly.

That means a Freestyle snapshot is not just "these files exist."

It includes:

• the filesystem
• installed packages and toolchains
• running processes
• process memory
• CPU state
• open runtime state inside the machine
• the machine's booted operating system state

If you snapshot a Freestyle VM after a dev server has started, the snapshot can preserve the already-running server state. If you snapshot after a browser is open, the snapshot can preserve that browser's state. If you snapshot after a database has warmed caches and accepted writes, the snapshot captures the machine at that point.

Freestyle also supports declarative VmSpec snapshots. A VmSpec can define files, Git repositories, systemd services, users, groups, environment variables, and base image configuration. Freestyle can cache those snapshot layers so future VMs start quickly, then apply per-VM changes on top.

So Freestyle gives you both sides:

• image-like reproducible setup through specs and cached snapshot layers
• full-machine checkpointing through VM snapshots that include memory, disk, and CPU state

That second part is where the power is.

Why the difference matters

Imagine an agent building a Next.js app.

With an image/template snapshot, you can start from an environment that already has Node, pnpm, Chrome, and common packages installed. That saves setup time. But the sandbox still has to start the dev server, compile the app, open ports, warm framework caches, maybe run a database, and get itself into the useful state.

With a Freestyle VM snapshot, the dev server can already be running. The process tree can already exist. Ports can already be open. The browser can already be sitting on the page the agent needs to inspect.

For an agent product, this changes the shape of the interaction.

The slow part is often not "install Node." The slow part is getting a real workspace back to the exact state where useful work can continue. Agents spend a lot of time in that middle state: dependencies installed, processes running, browser open, repo dirty, test watcher active, database seeded, and the previous attempt still visible in the terminal.

Filesystem templates help you rebuild that state faster.

Full VM snapshots let you keep it.

Daytona snapshots vs Freestyle snapshots

Daytona snapshots are useful. They are not fake. They solve a real problem.

But if you are building agents that need to preserve live state, the Freestyle primitive is stronger.

Daytona sandboxes and Docker-in-Docker

Daytona's docs describe sandboxes as full composable computers for AI agents. They support package installation, servers, code execution, filesystem access, process management, SSH, VNC, previews, and network controls. Daytona is a serious sandbox product.

They also document Docker-in-Docker support. You can create a Docker-in-Docker snapshot using prebuilt docker:dind images or install Docker manually in a custom image. Then you can run Docker Compose inside the sandbox for things like Postgres, Redis, MySQL, and multi-container development environments.

That is useful, but Docker-in-Docker is not nested virtualization.

Docker-in-Docker means you run a Docker daemon inside the sandbox, then run containers inside that daemon. It is a way to run containerized services from inside a managed environment. It is great when the inner workload is itself container-shaped.

Nested virtualization means the guest machine can use hardware virtualization features to run VMs inside the VM. That is a different level of system capability. It matters if your workload needs KVM, QEMU, Firecracker-like runtimes, Android emulators, custom hypervisor experiments, or infrastructure that expects to be able to create real virtual machines underneath it.

Freestyle VMs support nested virtualization. The VM can be the environment, and it can also be the host for other virtualization stacks.

That is one of the reasons Freestyle VMs are more powerful than sandbox-shaped runtimes.

VMs are different from sandboxes

"Sandbox" describes a security and product goal: run code in a controlled environment.

"VM" describes a machine abstraction: a guest operating system with its own memory, disk, kernel boundary, process tree, and hardware-like interface.

Those are not mutually exclusive. A VM can be used as a sandbox. Freestyle VMs are sandboxes in the security sense, but they are full Linux VMs in the system sense.

This is why the word "sandbox" gets confusing. A sandbox can be:

• a JavaScript isolate
• a container
• a container with a nice SDK
• a microVM
• a full VM
• a restricted shell pretending to be enough Linux for the task

Those are wildly different systems with the same marketing word on top.

For agents, the underlying primitive matters because the agent eventually finds the missing part of the fake computer. It needs apt. It needs systemd. It needs real users and groups. It needs to run a browser. It needs to run Docker. It needs to keep a dev server alive. It needs SSH when the abstraction breaks. It needs to fork the current state and try multiple paths at once.

A sandbox API can expose some of those as special platform features. A VM gives the agent the normal Linux surface area and lets the platform enforce the isolation boundary underneath.

That is the cleaner model.

Why Freestyle VMs are more powerful

Freestyle VMs are built around the idea that agents need real computers, not just command execution.

The Freestyle VM docs describe them as full Linux virtual machines that start in under a second, pause and resume instantly, and can be forked mid-execution without interruption. They also support low-level access such as SSH, systemd, multiple users and groups, configurable networking, and running Linux-compatible software, including containers.

That gives agents a much larger capability envelope:

• full Linux VM semantics
• root access and SSH
• systemd services and startup tasks
• multiple Linux users and groups
• configurable networking and exposed ports
• Docker and other Linux tooling inside the VM
• nested virtualization for workloads that need real VM behavior
• suspend and resume with memory preserved
• live forking of running machines
• snapshots that include filesystem, memory, and CPU state
• declarative specs and cached snapshot layers for fast reproducible setup

The key point is not that every workload needs all of this on day one.

The key point is that agent products expand. A product starts with "run this code safely." Then users want a terminal. Then the agent needs a browser. Then it needs a database. Then it needs a dev server. Then the environment needs to persist overnight. Then the agent needs to fork a half-finished attempt and try three other approaches without rebuilding the world.

If your primitive is a container template, each new requirement becomes another provider-specific feature or workaround.

If your primitive is a VM, most of those requirements are just Linux.

When Daytona is the right fit

Daytona is a good choice when you want a broad sandbox platform with many SDKs, team controls, lifecycle APIs, Docker/OCI image compatibility, and reproducible sandbox templates.

If your workload is container-shaped, if your team already has Dockerfiles for the environments you want to run, or if you mainly need fast, repeatable sandboxes for agent code execution, Daytona is worth evaluating.

Daytona's snapshot model is also familiar. Most developers understand container images. Turning one into a sandbox template is a clean workflow.

When Freestyle is the right fit

Freestyle is the better fit when the environment needs to behave like a real machine.

Use Freestyle when your agent needs to:

• keep running processes alive
• preserve memory between turns
• resume instantly after idle time
• fork a live workspace for parallel exploration
• run systemd services
• support SSH debugging
• model multiple Linux users
• run Docker inside the environment
• use nested virtualization
• host a browser, database, app server, worker, and terminal together

That is the workload agents are moving toward: not one command in a box, but a live workspace where the agent and user both do real work.

The bottom line

A Daytona snapshot is primarily a sandbox template built from a Docker or OCI-compatible image. It is great for reproducible setup.

A Freestyle snapshot is a full-machine VM snapshot. It captures filesystem, memory, and CPU state. It is great for preserving and cloning live work.

That is why Freestyle VMs are more powerful for serious agent infrastructure. They do not just rebuild an environment quickly. They preserve the machine the agent was already using.

For short-lived code execution, a sandbox template may be enough. For app builders, coding agents, browser agents, persistent workspaces, multi-service environments, and production-grade agent infrastructure, use the primitive that gives the agent a real computer.