Reuse a prepared
build or test environment.
A pipeline could restore a VM with its tools and dependencies ready, fork copies for parallel tests, or try a deployment change from a known working state.
Git-like branching.
For live virtual machines.
Run your applications and runtimes inside the VM. zeo5 lets you snapshot live state, restore it, and fork independent copies—with copy-on-write memory and disk reducing duplication.
20 ms wake-up at 1 GiB · 30 ms at 2 GiB · Live forks in milliseconds
- 20 ms wake-ups of a 1 GiB VM, 30 ms at 2 GiB
- forks a live VM in milliseconds
- forkable from the guest itself
- copy-on-write memory and disk
- git-like lineage: a tree of snapshots
- hardware isolation: a kernel per VM under KVM
- one GPU, shared hardware OpenGL acceleration kept across forks and snapshots
inside the guest
A running VM can fork from the guest.
Illustrative workflowVM
workspace / mainLive environment
Select a branch · choose the checkpoint to roll back
Resumed. Ready to fork again.
20ms
Wake a 1 GiB VM
30ms
Wake a 2 GiB VM
Milliseconds.
Fork a live virtual machine
Snapshot wake timings with a warm VMM. Workload and host affect results. Measurement notes
Your software. Your use case.
Potential use cases.
zeo5 provides VM snapshot, restore and fork capabilities. You choose what runs inside and how to use them. Here are a few possibilities.
Reuse a prepared
Start with the runtime
already running.
For example, you could prepare a VM with Python loaded and waiting for code. A client could then send a script or test and start executing it in milliseconds, without starting a new interpreter each time.
Branch work
from inside the guest.
Your application could request a fork from inside its VM to try alternative steps. Checkpoint progress, fork those branches again, or restore an earlier state to retry.
Give each approach
its own environment.
An agent could use the same VM capabilities to branch a workspace, explore different approaches, and continue from the state it chooses.
How it works
Snapshot. Fork. Resume.
service.py
service = load_application()
service.run()
working state, ready to saveA whole environment, ready to wake.
01 / SNAPSHOTSnapshot a
Snapshot a
running machine.
Capture a running VM’s memory, disk and process state. Keep its tools, working configuration and progress as a starting point you can resume or branch from.
Memory · disk · running process state
workspace / main
“Try the change in a branch.”
Fork requested from inside the guestVM 01ExploreRunning
VM 02RefineRunning
VM 03ValidateRunning
Same state. Independent execution.
02 / FORKFork a
Fork a
live VM.
Create independent copies of a running VM in milliseconds. Forks can also be requested from inside the guest. Each copy inherits the starting state and can become the parent of further forks.
Try the branching example- checkpoint-01Shared starting point
- explore / checkpoint-02Alternative approach preserved
- refine / checkpoint-03Continue from here
- refine / fork-01Fork this branch again—or roll back
03 / RESUMEResume, branch again,
Resume, branch again,
or roll back.
Resume the state you choose, fork it again, or roll back to an earlier snapshot. Every branch stays connected to its origin in a Git-like tree. A 1 GiB VM wakes in 20 ms; a 2 GiB VM in 30 ms.
Fork a fork. Roll back. Repeat.Built underneath every branch
More environments.
Less duplication.
Copy-on-write memory and disk.
A separate kernel for every VM.
SHARED STARTING STATE
Branch A
its changesBranch B
its changesBranch C
its changes
its changesBranch B
its changesBranch C
its changes
Less duplicated
memory and disk.
Branches share their starting memory and disk state, then store their own changes. Copy-on-write reduces duplication compared with making a full copy of every VM.
VM 01ApplicationOwn kernel
VM 02ApplicationOwn kernel
KVM · hardware isolation
Hardware isolation.
A kernel per VM.
Each VM runs its own kernel under KVM, with hardware isolation between virtual machines.
Hardware-accelerated GPU VMs
Resume GPU rendering
across forks.
Snapshot a GPU-enabled VM and resume hardware-accelerated rendering in its forks. The recorded demo shows OpenGL on NVIDIA hardware.
See current GPU support
Less idle infrastructure
Keep the state.
Reduce the cost.
An environment can stay available without staying active. Share the starting state across branches, keep their changes, and suspend VMs while there is no work to do.
Share the base.
Store the changes.
Copy-on-write lets branches share clean memory pages. Each branch holds its own changes, reducing the memory needed compared with a full independent copy for every environment.
More branches.
Less duplicated storage.
Snapshots and forks share their disk ancestry and store changed blocks. Keep multiple environments and checkpoints without duplicating a complete disk for each one.
Pause the VM.
Keep its progress.
Suspend an environment while it waits for an API response, a human answer or its next request. Restore its saved state when work arrives, instead of keeping the VM running through the wait.
Work arrivesA request, response or answer
Resume & runContinue from saved state
Save & suspendWait for the next piece of work
Your application or orchestrator receives the event and wakes the VM. Snapshots still use storage, and warm pools have overhead. Actual cost savings depend on shared state, idle time, workload and how your infrastructure is billed.
See measured memory and disk usageA natural fit
Durable workflows.
Resumable machines.
With engines such as Restate and Temporal, your workflow tracks the steps. zeo5 could preserve the machine behind them—ready to resume, branch or wait.
Keep the environment
behind each step.
Save the VM after a completed step. A worker could restore that checkpoint for a retry, with its runtime, files and in-memory progress already in place.
Try alternatives.
Continue with one.
Fork a prepared environment for parallel work or competing approaches. Keep the chosen branch’s checkpoint and release the others, sharing unchanged memory and disk.
No CPU.
No memory while you wait.
Suspend the workload VM and release its active resources while waiting for a timer, response or human approval. Its state stays on disk, using no CPU or guest RAM while parked. When the event arrives, a worker could wake it and continue.
Saved snapshots use disk; the host’s warm pool retains a small memory overhead. A potential integration through your worker or service code. The engine keeps its journal and retry logic; zeo5 keeps VM checkpoints. Your integration coordinates the two and handles external side effects safely.
What it does
The numbers, as measured.
Wake a saved environment, branch a live machine, and keep only what changes. These measurements show what that means in time, memory and disk.
Measured on one 8-vCPU host in September 2026. Wake timings use an already-running VMM. Results depend on the host, workload and configuration; these are measurements, not performance guarantees. GPU restore timings are reported separately below.
Wakes in about 20 ms
A parked VM is a snapshot; waking it to a serving process takes 17–25 ms for a 1 GiB VM and 29–35 ms at 2 GiB. The pool keeps the VMM already running, so a wake is a restore, not a boot.
Forks a live VM in milliseconds
The parent pauses for 0.3 ms plus a sparse diff seal, 15–30 ms in all, and keeps running. One snapshot is then woken N times in parallel: three children are all ready 50–100 ms after the call, the fastest burst in 46 ms. Three wakes racing on one host contend for a moment; alone, a child is ready in ~25 ms.
Forkable from the inside
The guest itself asks to fork over a control channel, and the call returns twice: once in the parent, once in each child, with its index. Your application can branch its own running environment.
Git-like lineage
Every fork is a branch. A branch is a rename plus a sparse diff of memory and disk against its parent, so lineage is a tree, not a line; it has been nine levels deep in a single run.
Copy-on-write memory and disk
A child holds only the pages and blocks it changed: 3 MB of memory delta for a fresh child, 90 MB for one that loaded a whole toolchain. Nothing is copied up front.
Clones share memory
Clean pages are served from one shared copy. A woken 1 GiB VM costs about 20 MB at rest, and eight clones of one base share pages down to ~6 MB each in shared-base mode.
Sparse on disk
Images are hole-punched: a 1 GiB memory image is 90 MB on disk and a 1 GiB root filesystem is 186 MB. Diffs are as small as what changed.
Compactable
A deep chain can be flattened into a fresh root in about 8 s, restoring depth-0 wake times without losing the state.
Shares one GPU
A VM gets hardware OpenGL through a per-slot renderer on the host: 0.4 s from a parked snapshot to an awake VM with its GPU state back (0.9 s until Chrome, with its own 1 s restore timer, renders on the card), and a fork keeps it, the clone awake in 0.5–0.6 s with no context lost. The same page ran 28× faster than in a VM without one.
Hardware isolation
Every VM is a Firecracker microVM under KVM with its own kernel, its own network namespace, and a seccomp filter on the VMM.
Warm pools that scale
A parked slot is 3.4 MB of RSS and costs no CPU. A thousand warm slots fit in 2.5 GB; the address plan allows 16,384 per host.
Dead VMs answer commands
A finished VM is just a snapshot. Type into it and it wakes in ~25 ms, runs your command, and is released again. Its uptime continues from where it was frozen.
Fresh identity per clone
Each resume steps the clock to the host, reseeds the kernel RNG, and gives the clone a new boot id and machine id, so forks are not indistinguishable twins.
Zero-copy shared data
Read-only data mounts with DAX straight out of host page cache: one copy for every clone and nothing of it in the snapshot.
Recorded and replayable
Every run is a workspace: its events, every console, its states. View it later, replay it at any speed, or delete it and free its VMs and states.
GPU measurements: GTX 1080 Ti · NVIDIA 550 driver · OpenGL through VirGL. Current GPU support
One example: AI environments
See an agent
fork its own world.
A recorded run. Real virtual machines.
Follow the branches, compare their work, and continue with the winner.
A little more detail
Good questions.
What runs inside the VM?
You choose the applications, runtimes and tools in your guest environment. zeo5 provides the VM snapshot, restore and fork capabilities. Prepared Python runtimes, CI/CD pipelines, workflows and AI environments are examples of how you could use them.
What do the wake-up numbers measure?
20 ms for a 1 GiB VM and 30 ms for a 2 GiB VM describe snapshot wake-ups with an already-running VMM. These are benchmark figures, not cold-boot times or performance guarantees. Host, workload and configuration affect results. The interactive example is a concept demonstration, not a timed benchmark.
Can the VM initiate its own fork?
Yes. A fork can be requested from inside the guest. Your guest application can branch its own environment while preserving the starting state.
What is shared between branches?
Memory and disk use copy-on-write. Branches share their original state and keep their own changes. Each VM has its own kernel under KVM.
What does GPU resume support today?
The recorded GPU path supports hardware-accelerated OpenGL on NVIDIA hardware, including snapshot and fork resume. Vulkan, compute, video and resource reservations are not part of this demonstrated path. The shared GPU path is not intended for hostile tenants.
Does everything reconnect automatically after a restore?
The VM’s saved memory and disk state are restored. External connections and services may need to reconnect. We can walk through what this means for your workload in a live demo.
Your application. Your workflow. Your next branch.