Repository navigation
Releases: andreygrehov/range
Release list
v0.8.0
--gpus all shows the machine's NVIDIA GPUs inside an environment, on Linux as root, with the same flag as docker run --gpus all.
sudo range run --gpus all ghcr.io/ggml-org/llama.cpp:light-cuda-b11206 \
--mount hf://unsloth/gemma-3-270m-it-GGUF:/model -- \
llama-cli -m /model/gemma-3-270m-it-Q4_K_M.gguf -ngl 99 -st -p "Hi"- Range shows the host driver's libraries and tools, such as
libcuda.so.1andnvidia-smi, read-only at/usr/local/nvidia, where CUDA images look for them. - Range keeps the kernels CUDA compiles for your GPU. On a Tesla T4, this command answered in 3.1 s from the second run on. With Docker and nvidia-container-toolkit, every run took 112 to 127 s, because CUDA compiled the kernels again in each container.
- From nothing, the same command took 143.1 s with Range and 184.5 s with Docker.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12v0.7.0
Range opens an EBS snapshot, or the root disk of an AMI, from any machine with AWS credentials. It needs no volume, no instance and no network path to your VPC.
range shell ebs://ami-0123456789abcdef0
range run ebs://snap-0123456789abcdef0 -- cat /etc/os-release- From a MacBook, a command in an Ubuntu 24.04 snapshot took 6.3 s and moved 34.6 MB of its 7.5 GB. Starting an instance from the AMI took 21.9 s to the same command.
- An x86 server's snapshot opens on an Apple silicon Mac too. The shell and its commands are Range's own, from busybox, and the files are the snapshot's.
- Range reads ext4 and XFS: Ubuntu, Debian, Amazon Linux and RHEL. A snapshot of a running machine opens as its disk held it.
- AWS serves only snapshots that your account owns or that another account shared with it.
- When a session fails in Range's VM, Range now says why.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12v0.6.0
On Linux, Range no longer needs root. Without it, each session runs in a small VM of its own, with QEMU and KVM, and the VM stops with the session. Join the kvm group and install QEMU. As root, Range runs natively as before, and now loads the nbd module itself.
--mount .:/workshares a directory of this machine, read-write.-p 8000:8000publishes a port of the environment, and-e KEY=VALUEsets a variable.- Once a session reads an eighth of a large layer, Range downloads the rest of that layer whole. On a Mac, every cold run in our benchmark is now faster than Docker Desktop:
pip install12.2 s against 17.4 s,cargo build15.2 s against 16.7 s. - Range keeps each image's layout, so a warm open reads no layer index. A warm
range run python:3.12is ready in 0.6 s on a Mac and 0.8 s in the Linux VM. - Kept image layers stay within
--cache-size, least recently used out first. - A session ends when range ends, even when something kills range.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12Linux VM, 3
The kernel, modules and busybox Range boots its Linux VM from: with Virtualization.framework on a Mac, with QEMU and KVM on Linux. One archive for each architecture. Range downloads it once and checks its SHA-256. Built by scripts/vm-assets.sh from Debian's 6.12.107 cloud kernel and Alpine's busybox-static 1.37.0. New in 3: the XFS module, which the VM loads when a disk needs it.
v0.5.0
On a Mac with Apple silicon, Range no longer needs Lima. It boots a small Linux VM for each session with Virtualization.framework, and the VM stops with the session.
- A warm
range run python:3.12takes 0.9 s, down from 1.5 s with Lima. The very first run, VM download included, takes 5 s. - A tag is resolved once, then from a local cache, and checked again in the background.
range runexits with the workload's exit status.
Intel Macs keep Lima. RANGE_RUNTIME=lima keeps it on Apple silicon too.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12v0.4.1
With RANGE_REGISTRY_MIRROR set, a layer the mirror does not have yet is read from Docker Hub. Range still checks every byte against the layer's digest.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12Linux VM, 2
The kernel, modules and busybox Range boots its Linux VM from: with Virtualization.framework on a Mac, with QEMU and KVM on Linux. One archive for each architecture. Range downloads it once and checks its SHA-256. Built by scripts/vm-assets.sh from Debian's 6.12.107 cloud kernel and Alpine's busybox-static 1.37.0.
Linux VM for macOS, 1
The kernel, modules and busybox Range boots its Linux VM from on a Mac with Apple silicon. Range downloads this once and checks its SHA-256. Built by scripts/vm-assets.sh from Debian's 6.12.107 cloud kernel and Alpine's busybox-static 1.37.0.
v0.4.0
The first run of a popular image now starts about as fast as a later one. rust:1.82 on a Mac, from an empty cache: 15 s without the catalog, 2.8 s now.
- The catalog holds startup profiles for about 90 popular images. Range prefetches what startup reads.
RANGE_REGISTRY_MIRROR=mirror.gcr.ioreads Docker Hub images from a mirror, with Docker Hub as the fallback.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12v0.3.0
Popular images are now pre-indexed in range-index, so their first run is lazy too.
- Range fetches layer indexes from the catalog, all at once.
RANGE_INDEX_URLsets another catalog,offturns it off. range index IMAGE...builds indexes for a catalog. No root needed.
curl -fsSL https://github.com/andreygrehov/range/releases/latest/download/range_$(uname -s)_$(uname -m).tar.gz | tar -xz
./range shell python:3.12