Show HN: Smol machines – subsecond coldstart, portable virtual machines

Original Article ↗ Hacker News Discussion ↗

Overview & Goals

  • Project aims to be a replacement for containers by providing micro-VMs with container-like ergonomics and subsecond cold starts.
  • Built on a custom fork of libkrun and a heavily trimmed Linux kernel, targeting both Linux (KVM) and macOS (Apple’s hypervisor).
  • Positioned as an alternative to Docker/Firecracker/Kata/LXC: full VMs, not shared-kernel containers, but with similar UX (CLI, images, packaging).

Performance & Boot Time

  • Subsecond boot is attributed mainly to aggressively stripping unnecessary kernel modules and boot-time services (especially systemd-related), not to special tricks.
  • Commenters note it’s possible to push this even further (e.g., sub-10ms to PID 1) with stricter constraints, suggesting further optimization room.
  • Some skepticism/questions about comparisons to QEMU-based setups, but no detailed benchmark methodology is provided in-thread.

Packaging & Developer Ergonomics

  • Uses Docker/OCI images (e.g., alpine, python:3.12-alpine) from public registries as bases.
  • Supports packing a stateful VM into a single .smolmachine binary, conceptually like Electron for Linux VMs: ship app + VM together.
  • Pack is “stateful” in terms of disk, not currently memory snapshot/rehydration.
  • Directory mounts and host→guest file copy are supported; piping between VMs via CLI works.

Security & Isolation

  • Security model is that VM and VMM share a trust boundary; host must still isolate VMM via OS mechanisms (namespaces, UID/GID, etc.).
  • Concerns raised about libkrun’s virtio-fs and vsock behavior potentially exposing more of the host filesystem/network than expected.
  • Project acknowledges these issues and is planning mitigations (per-VM staging dirs, private mount namespaces, virtio-net).

Compatibility, Features & Roadmap

  • Current gaps: Windows support, Docker-in-VM, nested virtualization (for Vagrant), Kubernetes-in-VM (k3s), Proxmox integration; all discussed as planned or “feasible but not done.”
  • GPU passthrough is actively being implemented.
  • VM resources are intended to be “automatic”: memory via virtio-balloon, CPU oversubscribed; de-emphasizing explicit resource sizing.
  • Plans for an open-source orchestration layer and potential signing/verification of packed machines.

Use Cases & Feedback

  • Strong interest from people building AI/agent sandboxes, per-customer isolated backends, and reproducible dev environments.
  • Several users report positive early integrations and responsive maintainers, while others stress missing Docker/K8s/nesting as key drawbacks.