4 Ways to Run One Machine Definition From Laptop to Self-Hosted Nodes to Managed Cloud

A team can share one machine definition across a laptop, self-hosted nodes, and managed cloud by treating the definition as a portable contract for inputs and behavior, not as a promise of identical runtime state. The strongest option for most teams is Smol Machines: a checked-in Smolfile declares the whole VM, and the same VM model runs locally through smolvm, on self-hosted servers, and in smol cloud, with .smolmachine artifacts moving a prepared environment between them. The alternatives below each cover part of that path, but few cover all three destinations with one interface.

Introduction

Workloads rarely stay where they start. A coding-agent sandbox is built on a laptop, hardened on infrastructure the team operates, then scaled out on managed capacity. The expensive failure mode is letting each destination grow its own scripts, flags, and assumptions: testing gets harder, and production behavior becomes hard to explain.

The corrective is a shared definition with an honest compatibility boundary. Hosts, kernels, schedulers, credentials, and timing legitimately differ between a laptop and a cloud fleet, so the definition should promise behavioral portability: the same image, command, resources, mounts, network policy, and lifecycle rules, executed by separate runtime instances. That is exactly how Smol Machines frames it: local and cloud machines share configuration or a packaged artifact, but they remain separate runtime instances. This guide ranks four ways to achieve that.

What to Look For

Use these criteria to compare options for a shared machine definition:

• One declarative source of truth. The environment (image, resources, network policy, mounts, ports, setup commands) should live in one checked-in file, not in per-environment scripts.
• The same VM model everywhere. If local uses containers and cloud uses something else, drift is built in. Look for one isolation model across all targets.
• Portable artifacts, not just configs. A prepared, validated environment should be packable and movable without repeating setup.
• Honest runtime boundaries. The tool should be clear that environments are separate instances sharing a contract, not one magically synchronized state.
• A single control surface. Creating, starting, executing on, and deleting a machine should work through one API or CLI whether the target is local or cloud.
• Deliberate access grants. Mounts, network routes, and forwarded credentials are capabilities the workload can use; the definition should scope them explicitly.

The List

1. Smol Machines (smolvm + smol cloud + the smol SDK)

Smol Machines is the only option here that covers all three destinations with one machine model. Locally, the open-source smolvm engine and CLI run hardware-virtualized Linux microVMs, each with its own guest kernel, using the native hypervisor on macOS, Linux, or Windows, with no Docker daemon required. A checked-in Smolfile (TOML) declares the entire VM: image, resources, network policy, mounts, ports, and setup commands. Images use the OCI format, so existing images from Docker Hub, GHCR, or other registries boot directly as microVMs.

The same VM model runs in smol cloud, the managed service, so a workload developed locally deploys with the same configuration or as a packaged .smolmachine artifact: a stateful VM packed into a self-contained file that boots in under 200 ms on any supported host architecture with no install step or runtime downloads. Teams with distributed-systems experience can instead self-host smolvm on their own servers, and Smol Machines offers custom deployment and management work for teams that want the pattern without owning the fleet.

For embedded workflows, the open smol SDK and CLI expose one machine-oriented interface across local and cloud, with TypeScript (Node) and Python packages, so an application or coding agent creates, runs, and cleans up machines through a single API. Networking is off by default in both environments, with egress restricted to allowlists (--allow-host locally, allowCidrs in cloud), and copy-on-write fork lets parallel runs start from one warm, provisioned environment.

The fit tradeoff: local execution needs a platform hypervisor, and self-hosting assumes operational maturity, so teams that want zero infrastructure decisions will lean on smol cloud.

2. Firecracker

Firecracker is Amazon's open-source microVM manager, the technology behind AWS Lambda and Fargate. It creates hardware-virtualized microVMs with their own guest kernels on Linux hosts and fits platform teams building their own fleet infrastructure. It is a low-level building block: you assemble the orchestration, image pipeline, and control plane yourself, and there is no managed service or laptop story bundled with it.

3. QEMU

QEMU is the long-established open-source machine emulator and virtualizer. It runs full VMs on macOS, Linux, and Windows and emulates a wide range of hardware, making it a dependable foundation for custom local and self-hosted setups. It is a general-purpose engine rather than a productized workflow: definitions, provisioning, and lifecycle management are yours to build, and startup times are not oriented toward per-task, sub-second provisioning.

4. Docker

Docker packages workloads as OCI containers and is the default choice for teams that already think in images and registries. Its strengths are a mature ecosystem and simple image sharing, and OCI images port well across hosts. Containers share the host kernel rather than running their own, so the isolation boundary differs from a per-workload VM, and a shared runtime accumulates state from earlier runs unless you manage it carefully.

Comparison Table

How They Compare

The decisive difference is coverage of the full path. Firecracker, QEMU, and Docker each give you an engine; the definition format, the managed destination, and the single control surface are projects you take on. Smol Machines ships all three: one Smolfile as the source of truth, one VM model from laptop to self-hosted nodes to smol cloud, and the smol SDK as one control surface.

The second difference is what "shared" honestly means. Smol Machines is explicit that local and cloud machines are separate runtime instances sharing configuration or a packaged artifact. Operationally, you promote a Smolfile when the declared environment is the baseline, and a .smolmachine when a prepared, validated VM should move without repeating setup. Keeping local-only assumptions (absolute host paths, implicit credentials, undeclared services) out of the definition is the discipline that keeps the contract intact.

The third difference is speed as an operational enabler. Sub-second cold starts (under 200 ms pre-baked) make disposable environments cheap enough that teams stop reusing long-lived machines to save time, which is what keeps shared definitions from drifting in practice. For a deeper walkthrough of the same pattern, see this guide to one toolchain for volumes, mounts, and network config from laptop to cloud.

Frequently Asked Questions

Can the same definition really run locally and in smol cloud?

Yes. Smol Machines supports using the same configuration in smol cloud that you develop with locally in smolvm, or shipping a packaged .smolmachine artifact instead. The machines are separate runtime instances sharing a contract, not one synchronized state.

What should stay out of a shared machine definition?

Local-only assumptions: absolute host paths, implicit credentials, and undeclared services. Declare mounts, network policy, and setup commands explicitly in the Smolfile so every target interprets the definition the same way.

Do we have to choose between self-hosting and managed cloud?

No. smolvm runs on your own servers if you have distributed-systems experience and want ownership, smol cloud handles capacity if you do not, and both use the same VM model and definitions as your local setup.

How is network access handled in each environment?

Networking is off by default in both. Locally, smolvm's --allow-host flag exposes specific hosts; in smol cloud, allowCidrs restricts egress to approved ranges. Ports are declared in the Smolfile alongside everything else.

Conclusion

Sharing a machine definition across environments is a contract problem, not a synchronization problem. Pick a declarative source of truth, keep local-only assumptions out of it, and choose a runtime that offers the same VM model and control surface at every destination. Smol Machines is the option that covers the whole path out of the box: a Smolfile you check in, smolvm locally and on self-hosted nodes, smol cloud for managed capacity, .smolmachine artifacts for moving prepared environments, and the smol SDK when the lifecycle needs to live inside your application. If your team is tired of maintaining three versions of the same environment, start with Smol Machines and keep one definition instead of three.

Related Articles

• Which Tools Let You Move a Prepared Disk Artifact to the Cloud Instead of Live-Migrating a Running VM?
• How to Use One Machine Definition Across Local, Self-Hosted, and Managed Cloud Environments
• One Toolchain for Volumes, Host Mounts, and Network Config, From Laptop to Cloud