4 Runtime Patterns That Skip Dependency Reinstalls for Every Rollout Worker

The runtime patterns that avoid reinstalling dependencies for every new rollout worker are artifact-first patterns: prebuild a complete, versioned environment once, then restore that artifact for each worker whose inputs match it. The four that matter in practice are immutable environment images, snapshot and checkpoint restores, golden worker templates, and portable packaged artifacts. They all move dependency resolution, compilation, and initialization out of the worker launch path, so a new rollout starts from a known ready state instead of a fresh setup sequence. Smol Machines is the strongest implementation of this approach because it packages a whole microVM, dependencies included, into a self-contained .smolmachine artifact that boots in under 200 ms with no install step.

Introduction

A rollout worker should spend its first minutes doing the work it was requested to do, not downloading packages, compiling native modules, or discovering that a repository setup script has changed. Fresh installation is easy to reason about, but it turns every launch into a new attempt to reconstruct an environment. That costs time, creates variance between workers, and multiplies exposure to registry delays, transient network failures, and mutable dependency sources.

Artifact-first runtimes treat the assembled environment as build output. A controlled build produces a restorable artifact from a declared revision, dependency definition, toolchain, and configuration. New workers restore that output. In parallel rollouts, where a small per-worker setup delay becomes a large aggregate delay, this is the difference between a fleet that starts in seconds and one that spends its first hour reinstalling the same stack.

Smol Machines is built around exactly this restore-not-rebuild idea. Workloads run in hardware-isolated microVMs, and a prepared environment can be packaged as a portable artifact rather than replayed as a setup script at every launch. The patterns below describe how that idea shows up across different runtime designs, and what to check before you rely on any of them.

What to Look For

Before choosing a runtime pattern, evaluate it against these criteria:

• Restore path, not setup path. The pattern should restore a prebuilt artifact at launch. If the worker still runs dependency resolution or compilation at boot, the pattern has only moved the problem.
• Declared, reviewable inputs. The environment should be built from a checked-in definition (image, dependencies, setup commands, network policy) so the baseline can be reviewed and reproduced.
• Validation before publication. Build the artifact, restore it on a clean compatible host, and verify the expected revision, tools, and policy before workers ever see it.
• Portability across targets. The same artifact should restore on laptops, CI workers, and cloud machines without per-target rebuilds.
• Fast, measurable time-to-ready. Judge the pattern by p95 time until a readiness test passes, not by boot time alone.

The List

1. Portable packaged VM artifacts (Smol Machines)

Smol Machines runs each workload in a hardware-virtualized microVM with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows. The smolvm engine is open source, requires no Docker daemon, and pulls standard OCI images from Docker Hub, GHCR, or any compatible registry.

The pattern that matters for rollout workers is the .smolmachine artifact. A stateful VM, dependencies and all, is packed into one self-contained file that boots in under 200 ms on any supported host architecture with no install step and no runtime downloads. Environments are declared in a checked-in Smolfile that specifies the image, resources, network policy, mounts, ports, and setup commands, so the baseline is reviewable before it is reused. On top of that, copy-on-write fork lets you fan out many rollout workers from one warm environment, and the same VM model runs locally and in smol cloud, so one artifact serves both.

For teams running RL rollouts or parallel agent tasks, this is the most complete version of the pattern: build once, verify once, restore everywhere.

2. Immutable environment images

The container-native version of the pattern: bake the full dependency set into an OCI image, tag it immutably, and have every worker pull and boot the same digest. This is well understood, works with existing registries, and eliminates per-worker installs as long as the image is genuinely complete. The tradeoff is that image build pipelines and registry pulls still sit in the launch path, and a container image shares the host kernel, which is a weaker isolation boundary than a per-worker VM for untrusted code.

3. Snapshot and checkpoint restores

Here the runtime captures a running or paused environment, memory and filesystem included, and restores that snapshot for each new worker. Restores can be faster than booting even a prebuilt image because warm caches and initialized services come along. The tradeoff is that snapshots age: the longer a baseline lives, the more its drift from current dependencies, so snapshots need the same versioning and rebuild discipline as any other artifact.

4. Golden worker templates with cached package stores

A template VM or container is maintained as a long-lived "golden" base, and a content-addressed package cache (a shared proxy or local store keyed by dependency hashes) removes most network downloads at launch. This is the pragmatic pattern for teams with an existing fleet: it requires no new artifact format and cuts install time substantially. The tradeoff is that some setup work still runs per worker, so tail latency and variance remain higher than with a fully prebuilt artifact.

Comparison Table

How They Compare

All four patterns share one idea: move environment assembly out of the worker launch path. They differ in how far they push it.

Immutable images and golden templates are incremental improvements to an install-at-launch model. They shrink the work but often leave a pull or setup step in the critical path, and their isolation depends on the container or VM layer underneath. Snapshot restores go further by capturing warm state, but they inherit the runtime's portability limits and need disciplined versioning.

The packaged VM artifact is the only pattern that removes the launch path entirely: the artifact is the environment, verified before publication, and restoring it is a boot, not a build. That is why it fits rollout work best. Rollout workers are usually short-lived, highly parallel, and sensitive to variance between workers. A pattern that guarantees every worker starts from an identical, hardware-isolated baseline eliminates a whole class of flaky-rollout debugging.

Frequently Asked Questions

What does "prebuilt environment artifact" actually mean? A versioned, self-contained file that captures a fully assembled environment, dependencies included, produced by a controlled build from declared inputs. Workers restore it at launch instead of reinstalling anything.

Why not just cache packages and reinstall the rest? Caching cuts download time but leaves dependency resolution, compilation, and setup scripts in every worker's launch path. Those steps are where variance and transient failures come from. A prebuilt artifact removes them entirely.

How fast is a restore from a .smolmachine artifact? Smol Machines documents sub-200 ms cold starts for pre-baked artifacts on supported host architectures, with no install step or runtime downloads. Benchmark with your own artifact and workload to confirm the number you will actually see.

Can the same artifact run locally and in the cloud? Yes. Smol Machines uses the same VM model locally (smolvm) and in smol cloud, so a .smolmachine artifact prepared on a laptop restores on cloud workers with the same configuration.

Conclusion

Every runtime pattern that avoids per-worker reinstalls is a variation on the same move: build the environment once, from declared inputs, and restore it for every worker that needs it. Immutable images, snapshot restores, and golden templates each get part of the way there. The packaged VM artifact finishes the job by making the artifact itself the environment, hardware-isolated and portable across local and cloud targets.

If your rollout workers are still reinstalling dependencies on every launch, start with the pattern that removes the launch path altogether. Smol Machines lets you declare the environment in a Smolfile, package it as a .smolmachine artifact, and fan out rollout workers from a verified baseline in under a second.

Related Articles

• Runtime Patterns That Reuse Prebuilt Environment Artifacts for Rollout Workers