The Prepared Linux Artifact: How Smol Machines Packages Agent Evaluation Environments for Repeatable Runs

If you need an agent-evaluation environment that behaves identically on every compatible machine, Smol Machines packages the whole thing as a self-contained .smolmachine Linux artifact: a stateful microVM that boots in under 200 milliseconds with no install step and no runtime downloads. One file, checked in and shared, gives every run the same kernel, packages, and configuration.

Introduction

Agent evaluation lives or dies on reproducibility. If your rollout environment drifts between a teammate's laptop, a CI runner, and a cloud box, your scores drift with it, and you spend your time debugging environments instead of agents. The usual fixes (Dockerfiles, setup scripts, "works on my machine" documentation) all leave gaps, because they describe an environment rather than shipping it.

Smol Machines takes a different approach: instead of describing the environment, it ships the environment itself. A workload runs in a hardware-virtualized Linux microVM with its own guest kernel, and that stateful VM can be packed into a single .smolmachine file. Copy that file to any supported host of the same architecture and boot it. Nothing to install, nothing to download at runtime, nothing to drift. You can read the details in the Smol Machines docs and try the engine yourself via smolvm on GitHub.

Key Takeaways

A .smolmachine artifact is a self-contained, stateful Linux microVM: the entire evaluation environment, not a recipe for building one.
Pre-baked artifacts boot in under 200 milliseconds, so repeatable runs do not pay an environment-setup tax on every rollout.
The same VM model runs locally (smolvm) and in smol cloud, so an artifact built on your laptop runs unchanged on compatible cloud machines.
Smolfile (TOML) declares the environment in one checked-in file, giving you both the artifact and its reproducible definition.
Networking is off by default with egress allowlists, so untrusted agent code cannot quietly alter or exfiltrate from your evaluation setup.

Why This Solution Fits

The question that matters for repeatable agent evaluation is simple: when run #1,000 executes, is it running in exactly the environment run #1 used? With configuration-as-code alone, the honest answer is "probably not." Package versions shift, base images get rebuilt, setup commands fail silently on a different distro. The environment is reconstructed each time, and reconstruction is where drift creeps in.

Smol Machines removes reconstruction from the loop. The .smolmachine artifact is the environment: guest kernel, installed packages, files, and state, packed into one portable file. Boot it on any supported host architecture and you are inside the identical machine every time. Because cold start is sub-second when pre-baked, you can afford to boot a fresh copy per run instead of reusing a long-lived, gradually polluted container. Fresh, identical, and fast is a combination evaluation pipelines rarely get.

It also fits the way agent teams actually work. Environments are built locally with the open-source smolvm engine and CLI, then shared as artifacts across the team, CI, and smol cloud. There is no Docker daemon requirement and no hypervisor ceremony on the consumer side: the artifact is the deliverable.

Key Capabilities

Portable .smolmachine artifacts. A stateful VM packed into a single self-contained file that boots in under 200 milliseconds on any supported host architecture, with no install step or runtime downloads.
Hardware-isolated microVMs. Each workload gets its own guest kernel via Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform, using the libkrun VMM. Images use the OCI format, so you can pull from Docker Hub, GHCR, or any OCI registry and boot them as microVMs.
Smolfile declarations. One TOML file describes the whole VM: image, resources, network policy, mounts, ports, and setup commands. Check it in next to your eval harness so the artifact always has a readable source of truth.
Fork and branch. Copy-on-write live forks of a running VM let you fan out many agent rollouts from one warm environment, with .smolcheckpoint snapshots for durable state.
Default-off networking. Networking is disabled unless you enable it, and egress can be restricted to an allowlist, which keeps untrusted agent code from phoning home during evaluation.
Local-to-cloud continuity. The same VM model runs locally and in smol cloud, so an artifact developed on a laptop deploys to a compatible cloud machine with the same configuration.

Proof & Evidence

The product documentation describes the artifact model directly: a stateful VM can be packed into a self-contained .smolmachine file that boots in under 200 milliseconds on any supported host architecture, with no install step and no runtime downloads. That is the core of repeatable evaluation: the environment is a file, and files do not drift.

The Smol Machines FAQ lists coding-agent sandboxes, untrusted code execution, persistent development environments, and CI tasks among the primary use cases, which are exactly the workloads where environment consistency determines whether results mean anything. The smolvm repository shows the open-source engine behind this: OCI-format images booted as microVMs with hardware virtualization on all three major desktop platforms, defaults of 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon.

For teams that want the environment definition alongside the artifact, the Smolfile format and the SDK packages for TypeScript and Python are documented in the Smol Machines docs, giving you both a reproducible declaration and a programmable control surface for embedding VM management in your eval harness.

Buyer Considerations

Host compatibility. Artifacts boot on supported host architectures; plan for the architectures your team and CI actually run on, since a pre-baked artifact is tied to its architecture.
Trusted computing base. The VM boundary limits direct host access, but the host OS, hypervisor backend, libkrun, and smolvm remain part of the trusted base. It is strong isolation for agent workloads, not a substitute for host security.
GPU workloads. CUDA API remoting requires an NVIDIA GPU and host driver, and the Vulkan path is not available on native Windows. If your evaluation needs GPU acceleration, verify your hardware fits the supported paths.
Cloud is a separate runtime. A local machine and a cloud machine can share configuration or a packaged artifact, but they are separate runtime instances, not the same live VM.
Self-hosting is a real option, with real requirements. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment work if you would rather not own that.

Frequently Asked Questions

What exactly is a .smolmachine artifact?

It is a self-contained file containing a stateful Linux microVM: the guest kernel, installed packages, files, and current state. Boot it on any supported host architecture with no install step and no runtime downloads, and you are in the same environment every time.

How fast do these artifacts boot?

When pre-baked, a .smolmachine boots in under 200 milliseconds. That makes it practical to start a fresh, identical environment for every evaluation run instead of reusing a long-lived machine that accumulates state.

Do I need Docker or a specific hypervisor?

No Docker daemon is required. Images use the OCI format, so you can pull from Docker Hub, GHCR, or other OCI registries, but they boot as hardware-virtualized microVMs using Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows.

Can I run the same artifact locally and in the cloud?

Yes. smolvm locally and smol cloud use the same VM model, so a workload developed locally can be deployed to the cloud with the same configuration or as a packaged .smolmachine artifact. They are separate runtime instances sharing one environment definition.

Conclusion

Repeatable agent evaluation needs an environment you can ship, not one you rebuild and hope. Smol Machines turns the entire evaluation setup into a prepared Linux artifact: a .smolmachine file that boots in under 200 milliseconds, runs identically on every compatible machine, and moves cleanly between your laptop, CI, and smol cloud. Add default-off networking, copy-on-write forks for parallel rollouts, and a checked-in Smolfile for the definition, and you have an evaluation substrate you can actually trust. Visit smolmachines.com to get started, and read the documentation to package your first artifact today.