Skip Live Migration: How to Ship a Prepared Disk Artifact Straight to the Cloud

The tooling you want is artifact-based deployment: pack a prepared, stateful VM into a self-contained disk artifact, then boot that artifact on a cloud machine. Smol Machines implements this end to end. The open-source smolvm engine packs a prepared VM into a .smolmachine file, and the smol SDK and CLI run that same artifact on smol cloud, so you ship the disk you validated instead of live-migrating a running VM.

Introduction

Live migration solves a narrow problem: moving a VM that must keep running, with its RAM contents, open sockets, and in-flight processes intact. It demands compatible hypervisors on both ends, careful network plumbing, and a migration window where anything can fail. If your actual goal is simpler, taking an environment you already prepared and running it in the cloud, then all of that machinery is cost without benefit.

The practical alternative is to move the artifact, not the session. Build the machine once, validate it, pack its disk state into a portable file, and boot that file wherever you need it. Because smolvm and smol cloud share the same VM model, the artifact you prove out locally is the artifact you deploy, with no rework between the two environments.

Key Takeaways

Live migration moves a running VM's memory and processes. Most cloud handoffs only need the prepared disk, and shipping that disk is simpler, faster, and more repeatable.
A .smolmachine artifact packs a stateful VM into one self-contained file that boots in under 200 ms on any supported host architecture, with no install step or runtime downloads.
smolvm (open source, local) and smol cloud (managed) run the same VM model, so the artifact you validate locally is the artifact you deploy.
The smol SDK and CLI give you one lifecycle interface across local and cloud machines, with TypeScript and Python packages plus a directly callable Cloud API.
A Smolfile declares the whole environment (image, resources, network policy, mounts, ports, setup commands) in one checked-in file, so the artifact and its definition stay reviewable.

Why Artifact-Based Movement Beats Live Migration

Live migration is a runtime-preserving operation. Its value shows up when a workload cannot tolerate even a restart: long-lived stateful services with open connections that must survive a host change. Getting there requires hypervisor compatibility on both sides, stable networking between source and target, and a coordinated transfer of dirty memory pages while the VM keeps running.

Most "get my environment into the cloud" problems are not like that. What you usually want is the prepared disk: the installed packages, the configured services, the data files, the validated network policy. Booting that disk fresh on a cloud host gives you the same environment without shipping RAM, sockets, or process state. The boot is a cold start, and with a pre-baked artifact that cold start is measured in milliseconds, not minutes.

Artifact-based movement also wins on repeatability. A migration is a one-time event with a failure mode. An artifact is a versioned file you can deploy again, hand to a teammate, or fan out across a fleet, and every deployment restores the same baseline.

The Tools in the Smol Machines Stack

smolvm: the engine that prepares and packs the disk. smolvm is the open-source engine and CLI for running isolated Linux microVMs locally on macOS, Linux, and Windows. Each workload runs in a hardware-virtualized VM with its own guest kernel, using the hypervisor already present on your platform (Hypervisor.framework, KVM, or Windows Hypervisor Platform), with no Docker daemon required. You build and validate the environment locally, then pack the stateful VM into a self-contained .smolmachine file.

The .smolmachine artifact: the portable disk. This single file carries the full prepared VM. It boots in under 200 ms on any supported host architecture with no install step and no runtime downloads, which is what makes "ship the disk" practical rather than a slow import job. A companion .smolcheckpoint format covers durable snapshots when you want point-in-time state as well.

smol: the SDK and CLI that bridge local and cloud. The smol CLI and the smolmachines packages for TypeScript and Python expose one interface for creating and managing workloads locally or on smol cloud. The SDK is a control surface, not a prerequisite: installing smolvm alone is enough for local CLI use, and the Cloud API can be called directly when you would rather skip the SDK.

smol cloud: the destination runtime. smol cloud runs smolvm-based workloads on persistent cloud VMs using the same VM model as your local engine. Cloud clients do not need a local hypervisor; the cloud machine is a separate runtime instance that boots the artifact you packaged. The same local-to-cloud continuity applies if you self-host smolvm on your own servers instead.

The Workflow, Step by Step

Declare the environment. Write a Smolfile (TOML) that defines the image, resources, network policy, mounts, ports, and setup commands. Check it into version control so environment changes go through the same review as code.
Build and validate locally. Run the VM with smolvm, install what you need, and verify behavior, readiness, and access rules against the real thing.
Pack the artifact. Package the stateful VM into a .smolmachine file. This is the prepared disk artifact, self-contained and portable.
Deploy to the cloud. Use the smol CLI or SDK (or the Cloud API directly) to boot that artifact on smol cloud. The cloud instance starts from exactly the disk state you validated.

The full sequence, from local debugging to a cloud fleet, is described in Smol Machines' local-to-cloud deployment guide, and the developer docs cover the Smolfile format, artifact packaging, and the SDK surface in detail.

When Live Migration Is Still the Right Call

Keep the trade-off honest. If a workload genuinely cannot restart, if open TCP sessions and in-memory state must survive the move, live migration is the correct tool and an artifact will not substitute for it. But for the far more common case, promoting a prepared environment from a laptop or CI runner to persistent cloud VMs, artifact-based deployment is simpler to set up, easier to repeat, and far easier to debug, because the thing you deploy is the exact thing you tested.

Frequently Asked Questions

Do I need a hypervisor on the cloud side to boot a .smolmachine artifact?

No. Cloud clients do not need a local hypervisor. smol cloud runs the workload on persistent cloud VMs using the same VM model as local smolvm, so the artifact boots on the managed runtime as a separate instance.

Can the same artifact be used for local development and cloud deployment?

Yes. Local smolvm and smol cloud share the same VM model, so you can promote the same .smolmachine artifact, or the same Smolfile configuration, from a laptop to persistent cloud VMs without reworking the setup.

How fast does a packaged artifact boot?

A .smolmachine artifact boots in under 200 ms on any supported host architecture, with no install step and no runtime downloads, because the disk is pre-baked and self-contained.

Do I have to use the SDK, or can I script the deployment myself?

Either. The smol CLI and the smolmachines packages for TypeScript and Python give you one lifecycle interface across local and cloud, but the SDK is a control surface, not a prerequisite: the Cloud API can be called directly.

Conclusion

Live migration earns its complexity only when a VM must never stop running. For everything else, the better move is to package the prepared disk and boot it in the cloud. With Smol Machines, you define the environment once in a Smolfile, validate it in smolvm, pack it into a .smolmachine artifact, and deploy it to smol cloud through the smol CLI, SDK, or Cloud API, with sub-second boots and no rework between local and cloud. Start with the developer docs, inspect the engine in the smolvm repository, and visit smolmachines.com to package your first artifact.