Give Every Pull Request Its Own Disposable Machine: The CI Isolation Setup That Cleans Up After Itself

External pull-request code should run in a fresh, hardware-isolated microVM for each job, with networking off by default, only the mounts and credentials the job actually needs, and teardown enforced by the machine lifecycle itself rather than a cleanup script at the end of the pipeline. Smol Machines is built for exactly this pattern.

Introduction

Code that arrives from an outside contributor is useful and untrusted at the same time. A test script in a pull request can read its environment, spawn subprocesses, write to a shared workspace, consume CPU and disk, or make outbound network requests. If that code runs on a persistent runner, the next build can inherit files, processes, credentials, or resource pressure from the last one. The usual mitigation, a cleanup command at the bottom of the pipeline, is not a boundary: jobs time out, get canceled, or fail before the final step ever runs. Cleanup has to be a property of the execution environment, not an optimistic shell step your pipeline hopes to reach.

That is the case for a microVM-based execution layer where every job is an owned, short-lived machine. Smol Machines runs each workload in a hardware-virtualized Linux VM with its own guest kernel, boots pre-baked machines in under 200 milliseconds, and makes deletion part of the machine lifecycle. You can start with the open-source smolvm engine, read the documentation, or go straight to Smol Machines to give every pull request its own disposable machine.

Key Takeaways

Treat external pull-request code as untrusted by default and run each job in a fresh, hardware-isolated microVM with its own guest kernel, not beside other work in a shared host kernel.
Cleanup must be enforced by the machine lifecycle (stop and delete through a controller), not by a script at the end of the pipeline that may never run.
Networking should start closed. Egress can be restricted to an allowlist so untrusted code cannot phone home unless you explicitly allow it.
Sub-second cold starts (under 200 ms for pre-baked .smolmachine artifacts) make per-job isolation practical instead of a throughput tax.
A declarative Smolfile keeps the entire grant surface (image, resources, network policy, mounts, ports, setup commands) in one reviewable, checked-in file.

Why This Solution Fits

A CI system executing outside contributions needs four things at once: a strong isolation boundary, minimal default access, controlled export of results, and guaranteed teardown. Most execution layers give you one or two of these and leave the rest as pipeline homework.

Containers share the host kernel, so a hardening mistake can put untrusted code closer to the host than you intended. Self-hosted runners can be wiped between jobs, but the wiping is your script, and your script is exactly what a failed or canceled job skips. Smol Machines moves all four requirements into the platform:

The boundary is hardware virtualization. Each workload runs in a VM with its own guest kernel (libkrun VMM and libkrunfw guest kernel), so escaping the job's controls means breaching a separate kernel boundary first, not the host kernel.
Cleanup is lifecycle, not convention. Machines are created, started, stopped, and deleted through a programmatic control plane. When the job ends, in any state, the controller terminates and deletes the machine.
Defaults are restrictive. Networking is off unless enabled, egress can be limited to an allowlist, and protected host config and log trees are blocked by default.
Speed removes the excuse. Pre-baked machines boot in under 200 ms, so giving every pull request its own machine costs about as much as reusing one.

The result is a CI setup where the safe path and the fast path are the same path.

Key Capabilities

Hardware-isolated microVMs per job. Each workload gets its own guest kernel behind a hypervisor (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows), with 4 vCPUs and 8 GiB RAM by default and elastic memory via virtio balloon.
Default-off networking with egress allowlists. Untrusted code cannot reach the internet unless you allow it, and --allow-host (smolvm) or allowCidrs (smol cloud) limits egress to exactly the hosts a job needs.
Declarative Smolfile environments. A single TOML file declares the image, resources, network policy, mounts, ports, and setup commands for the job environment, checked into the repository and reviewed like any other code.
OCI image compatibility. Jobs boot from the same images you already build: pull from Docker Hub, GHCR, or any OCI registry and run it as a microVM, with no Docker daemon required.
Programmatic lifecycle control. The open smol SDK (TypeScript and Python) and smol CLI expose create, start, stop, and exec operations, so your CI controller owns the full machine lifecycle, including deletion after success, failure, or cancellation.
Portable artifacts. A prepared environment packs into a self-contained .smolmachine file that boots in under 200 ms on any supported host architecture, with no install step or runtime downloads at job time.
Local-to-cloud continuity. The same VM model runs locally with smolvm and as a managed service in smol cloud, so a job environment validated on a laptop runs unchanged in CI.

Proof & Evidence

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

The developer documentation covers the Smolfile format, machine lifecycle operations, and artifact packaging.
The smolvm repository is open source, so you can inspect the engine, the CLI, and the hypervisor backends yourself.
The egress allowlist guidance documents the --allow-host flag for smolvm and allowCidrs for smol cloud.
The guide to isolated machine APIs describes the create, start, stop, execute, and delete lifecycle a CI control plane needs.
The sub-second cold start is the easiest claim to verify: package a prepared environment as a .smolmachine and time the boot on your own hardware.

Buyer Considerations

A microVM is the primary boundary, not the whole answer. Capabilities you explicitly grant, such as writable host mounts, unrestricted egress, or powerful credentials, still bypass it. Make every mount, secret, and egress route a deliberate decision.
Trusted computing base. Each smolvm runs with the invoking host user's permissions, and the host OS, hypervisor backend, libkrun, and smolvm are in the trusted computing base. Keep those components patched.
Self-host or managed. Teams with distributed-systems experience can run smolvm on their own servers; smol cloud offers the same VM model as a managed service. Smol Machines also offers custom deployment and management work.
Hypervisor availability. smolvm needs a hypervisor backend on the host (Hypervisor.framework, KVM, or Windows Hypervisor Platform). Cloud clients do not need a local hypervisor.
Start with the riskiest jobs. You do not have to migrate every pipeline at once. Move external pull-request builds first, where the trust boundary is weakest, and expand from there.

Frequently Asked Questions

Why not just use containers with a cleanup step?

A container shares the host kernel, and a cleanup step is a script your pipeline may never reach. A microVM gives the job its own guest kernel behind a hypervisor, and deletion is enforced by the machine lifecycle rather than by convention.

Can we keep our existing CI images?

Yes. Smol Machines uses the OCI image format, the same standard Docker uses, so images from Docker Hub, GHCR, or other registries boot directly as microVMs. Containers can also run inside a guest when needed.

How fast is a per-job machine, really?

Pre-baked .smolmachine artifacts boot in under 200 milliseconds on supported host architectures, with sub-second cold starts generally. That is fast enough to give every pull request its own machine without slowing the pipeline.

Does this work for self-hosted runners and cloud CI?

Both. smolvm runs locally on macOS, Linux, and Windows for self-hosted runners, and smol cloud runs the same VM model as a managed service. A .smolmachine artifact moves a workload between them without reconfiguration.

Conclusion

External pull-request code deserves the same skepticism you would apply to any untrusted program: its own machine, minimal access, a closed network by default, and teardown that cannot be skipped. Smol Machines packages that pattern into a platform with sub-second boots, a declarative Smolfile, and one VM model from laptop to cloud.

Start with the open-source smolvm engine, read the documentation, or visit Smol Machines to give every pull request its own disposable machine.