ROAMVM GitHub

Kubernetes-native virtual machines

YOUR VM.
ANY NODE.

A full Linux machine.
A disk that travels with it.
Compute wherever there’s room.

Explore the system Read the docs

Built for development. Built in the open.

FIG. 01 / PORTABILITY
One VM, a new place to run A virtual machine moves from node A to node B through durable state in object storage. STOP. SAVE. START ELSEWHERE. NODE A NODE B VM RELEASED RUNNING YOUR DISK
Same machine. New placement.01—02
Cloud Hypervisor / KVMOCI base imagesS3-compatible stateOrdinary Kubernetes

01 The system

THREE PLACES.
ONE MACHINE.

Software, state, and compute each have a home. Only the working copy needs to be where the VM is running.

A / OCI REGISTRY

THE BASE.

Your immutable Linux disk, packaged as an OCI image. Pin a digest; let the node pull and cache it.

Shared software. Standard distribution.

B / OBJECT STORAGE

YOUR CHANGES.

Projects, packages, settings. Save the entire changed root disk to S3 on stop, ready for the next start.

One current checkpoint. No history pileup.

C / THE SELECTED NODE

THE WORKING COPY.

A local copy-on-write disk in a fresh temporary PVC. Fast storage while you work; disposable after a durable stop.

Local I/O. No permanent root claim.

02 The lifecycle

PICK UP WHERE
YOU LEFT OFF.

Stop the machine. Keep its disk.
Start again wherever Kubernetes finds capacity. Try the sequence below.

01 / START

LET THE SCHEDULER CHOOSE.

Kubernetes places the runner Pod. The runtime mounts the OCI base, restores the saved changes, and boots the VM on node A.

roamvm start devbox

A normal Pod owns placement, resource requests, and networking.

03 A familiar interface

ONE RESOURCE.
YOUR VM.

Declare a VirtualMachine. Choose its CPU and memory. Use the Kubernetes tools you already have.

Installation guide

Install the runtime and publish a Linux image first. The example needs your real image digest.

DEVBOX.YAML 
apiVersion: vm.roamvm.io/v1alpha1
kind: VirtualMachine
metadata:
  name: devbox
spec:
  powerState: Running
  image: registry.example.com/devbox@sha256:<digest>
  cpus: 4
  memory: 8Gi
  resources:
    requests:
      cpu: "1"
  readinessPort: 22
kubectl apply -f devbox.yaml

4 guest vCPUs. 1 CPU reserved. Burst into available capacity.

04 Deliberate boundaries

BUILT FOR
YOUR NEXT
WORK SESSION.

EXPERIMENTAL SOFTWARE

For personal machines, development environments, and test clusters. The runtime is tested with real KVM guests; production deployments need their own qualification.

See what’s tested
What survives a stop?

The full changed root disk: project files, installed packages, and settings. A successful stop replaces the previous saved checkpoint. Memory and running processes do not resume.

What if a node fails?

Changes since the last completed stop may be lost. Recovery requires fencing the previous VM before restoring its last checkpoint. There is no automatic failover or continuous replication.

Read the failure model
Does it work with Coder?

Yes. Coder can create and control these VMs through a template. RoamVM itself is independent of Coder: people and tooling can use the same VirtualMachine resource directly.

What does my cluster need?

Linux x86-64 nodes with KVM/TUN, Kubernetes 1.35+ with image volumes, compatible containerd, IPv4 networking, an S3-compatible store, and local working storage with delayed volume binding. The installation guide covers the device plugin and networking permissions.

Check the requirements
Can it migrate while running?

Movement is a graceful stop followed by a start. Live migration, online root-disk growth, and periodic checkpoints are not implemented. Secondary PVCs retain their own storage placement constraints.