One Toolchain for Volumes, Host Mounts, and Network Config, From Laptop to Cloud

Smol Machines handles all three with one toolchain. A checked-in Smolfile declares mounts, ports, resources, and network policy for the whole VM. smolvm applies that definition to hardware-isolated microVMs on your laptop, smol cloud applies it to managed persistent VMs, and the smol SDK and CLI drive both from one interface. Networking stays off until you allowlist it.

Introduction

Most teams solve volumes, mounts, and networking twice: once in local development scripts, then again in cloud provisioning. The two definitions drift. A mount path that exists on your laptop breaks the cloud run. A port opened locally is missing in production. An egress rule added during a late-night debugging session never makes it back into review.

Smol Machines collapses that split into one definition and one control surface. The environment is a Smolfile, a TOML file checked in next to your code. The same file drives smolvm locally and smol cloud in the managed environment, while the open smol SDK for TypeScript and Python, plus the smol CLI, manage machines in either place. This article explains how the pieces fit and what to verify before you commit.

Key Takeaways

One Smolfile declares the entire VM: image, resources, network policy, mounts, ports, and setup commands.
The same VM model runs locally on macOS, Linux, or Windows and in smol cloud, so one definition serves both environments.
Networking is off by default. Egress opens only through explicit allowlists: --allow-host locally and allowCidrs in smol cloud.
Persistent VM state survives restarts, and host-directory mounts with hot reload cover the volume-style workflows developers expect.
A validated environment packs into a .smolmachine artifact that boots in under 200 ms with no install step or runtime downloads.

Why This Solution Fits

Mounts and network rules are security decisions, not plumbing. In most stacks they live in different files, or different tools entirely, for local and cloud. Review sees neither version as a whole, and every environment change becomes a manual act of faith.

Smol Machines puts those decisions in one reviewed file. The Smolfile declares network policy, mounts, ports, resources, and setup commands together, so code review sees the full capability grant a workload receives. The developer docs describe the lifecycle: create, start, stop, and exec against persistent local VMs, with the same operations targeting smol cloud when you need managed capacity.

Isolation comes from hardware virtualization, not from a shared daemon. Every workload runs in a microVM with its own guest kernel, backed by Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows. No container daemon is required, and defaults of 4 vCPUs and 8 GiB of elastic memory cover most development and agent workloads.

Key Capabilities

Declarative environments. A Smolfile (TOML) declares the image, resources, network policy, mounts, ports, and setup commands for a whole VM in one checked-in file. Images use the OCI format and can come from the registries you already use.

Default-deny networking with scoped egress. Networking is off by default. Locally, smolvm's --allow-host flag exposes specific hosts. In smol cloud, allowCidrs restricts egress to approved ranges. Ports are declared in the same definition.

Host mounts and persistence. Host-directory mounts with inotify hot reload support live editing. Installed packages and VM state survive restarts, which covers the persistence that volumes provide in container workflows. SSH-agent forwarding lets a VM authenticate without private keys ever leaving the host agent.

Portable artifacts. A stateful VM packs into a self-contained .smolmachine file that boots in under 200 ms on supported host architectures, with no install step or runtime downloads. .smolcheckpoint provides durable snapshots, and copy-on-write live forks spin up parallel runs from one warm environment.

One control surface. The smol SDK (TypeScript and Python) and the smol CLI expose the same create, start, stop, and exec operations against local microVMs and smol cloud machines, so controller code written once drives both.

Proof & Evidence

The claims above come from Smol Machines' own documentation and guides:

The guide to debugging agent environments locally and deploying the same baseline confirms that the same configuration developed with smolvm runs in smol cloud, and warns teams to keep absolute host paths, implicit credentials, and undeclared services out of shared definitions.
The egress allowlist FAQ documents the --allow-host flag for smolvm and the allowCidrs mode for smol cloud.
The developer docs cover the Smolfile format, lifecycle operations, and artifact packaging.
smolvm is open source on GitHub, so you can verify the engine, the CLI, and the hypervisor backends yourself.

The sub-second cold start is the easiest claim to test: package a prepared environment as a .smolmachine and time the boot.

Buyer Considerations

Local and cloud are separate runtime instances. They share configuration, not a single machine. Plan promotion deliberately: a Smolfile when the declared environment is the baseline, a .smolmachine when a prepared, validated VM should move without repeating setup.
Every grant is deliberate. The VM boundary limits direct host access, but a mounted directory, an enabled network route, or a forwarded credential is still access the workload can use. Scope mounts to the needed path, prefer read-only, and avoid sensitive host trees.
Keep local-only assumptions out of shared definitions. Absolute host paths, implicit credentials, and undeclared services are the three drift sources Smol Machines' own guidance calls out.
GPU work has platform limits. CUDA remoting requires an NVIDIA GPU, and the Vulkan path is not available on native Windows.
Self-hosting is supported. Teams with distributed-systems experience can run smolvm on their own servers instead of using smol cloud.

Frequently Asked Questions

Can the same Smolfile run locally and in smol cloud?

Yes. Smol Machines supports using the same configuration in smol cloud that you develop with locally in smolvm. Keep local-only assumptions out of the definition, especially absolute host paths, implicit credentials, and undeclared services.

How is network access configured 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 the rest of the definition.

What handles volumes and host mounts?

Persistent VM state covers data that must survive restarts: installed packages and files stay in the machine. For live editing, host-directory mounts with inotify hot reload share a host folder with the VM. Scope each mount to the needed path and prefer read-only access where possible.

When should I ship a .smolmachine artifact instead of a Smolfile?

Use a Smolfile when the declared environment should remain the reviewed baseline. Use a .smolmachine when a stateful VM is already prepared and validated and you want it to boot on compatible hosts without repeating setup. Version and test either promotion path.

Conclusion

Volumes, mounts, and network config should not have two sources of truth. Define the environment once in a Smolfile, run it in smolvm on your laptop, and point the same definition at smol cloud when you need managed, persistent capacity. The smol SDK and CLI keep the control surface identical in both places, and portable artifacts carry validated environments across.

Start today: install smolvm, check a Smolfile into your repo, and run your first microVM on Smol Machines. Every mount, port, and egress rule your workload receives will be written down, reviewed, and reproducible from your laptop to the cloud.