Run your app as its own virtual machine.

jerboa turns a Linux program into a bootable image with its own kernel, and runs it as a Firecracker or QEMU VM.

Source to responsebuild, boot and first HTTP answer: 859 ms

< 1 s

HTTP requests per secondagainst Docker on macOS, Go server

1.9×

Random disk readsagainst Docker on macOS, fio 4k

6.3×

A recorded session

Build a Go web server, start it as a VM and request a page. Recorded on an Apple M5; the transcript is unedited.

$ jerboa build . --name web  Building project...  ✓ Build complete  Assembling image on daemon...  ✓ web:latest  ·  10.4MB  ·  built in 659ms$ jerboa run -d -p 8080:8080 --name web webe6cf1bf78d40Started in 27ms$ curl localhost:8080hello from a linux/arm64 unikernel$ jerboa psID            NAME  STATE    HEALTH  IMAGEe6cf1bf78d40  web   running          sha256:8e36de256043…$ jerboa stats webState   runningCPU     0.0%Memory  59.4 MiBDisk    3.4 MiB

One kernel per app

A container shares the host’s kernel with every other container. A jerboa VM carries its own Nanos kernel behind the hypervisor, with no shell, no init and no other process.

Commands

The workflow follows containers: build, run, publish, network, mount. Every command below comes from the documentation.

# Go, Node.js, Python and Rust projects are detected
jerboa build . --name web

# Drop the boot code and the second kernel copy
jerboa build . --name web --layout compact

# See which programs and packages fill the image
jerboa build . --name web --size-report

# redis starts through a shell script, so point --file
# at the real binary: a unikernel runs one program, no shell
jerboa pkg from-docker redis:7.2 redis:7.2 \
  --file /usr/local/bin/redis-server
jerboa build . --name redis

jerboa network create app
jerboa run myapp:latest --network app -p 8080:80 --name web

# Bind a published port to localhost only
jerboa run myapp:latest --network app -p 127.0.0.1:8080:80

jerboa network create app
jerboa run mysql:latest --network app --name db -p 3306:3306
jerboa run myapp:latest --network app --name web -p 8080:8080 -e DB_HOST=db
# inside `web`, the hostname `db` resolves to the db VM's IP

jerboa volume create data --size 1G
jerboa run myapp:latest -v data:/var/data

# Seed a volume from a package at creation
jerboa volume create pgdata --size 1G --seed-pkg eyberg/postgresql:11.3.0 --src /db
jerboa run postgresql -v pgdata:/db --network pgnet -p 5432:5432

version: "1"
services:
  api:
    image: api:latest
    memory: 256M
    networks: [app]
    ports:
      - "8080:8080"
    health_check: "http:8080:/healthz"
    restart: "on-failure:5"
networks:
  app:
    driver: bridge
    subnet: 10.100.0.0/24

# jerboa compose up stack.yaml

jerboa logs <vm-id> -f
jerboa stats web
jerboa inspect web

jerboa snapshot create <vm> <name>    # pause, capture, resume
jerboa snapshot restore <vm> <name>   # stopped VM -> running, in place
jerboa snapshot ls

Against Docker

Same binaries on both sides, runs interleaved, medians of at least three. jerboa is ahead at start-up, random disk reads and, on macOS, request-heavy apps. Docker is ahead at sequential writes, at sending from a VM to the host on macOS and, on Linux, for clients on the LAN.

Trade-offs

A unikernel trades flexibility for isolation and size. These are the limits you hit first.

One process per VM

Nanos has no fork, no exec and no shell. Entry-point scripts must point at the real binary; tools that spawn helpers, like PostgreSQL’s initdb, run at build time.

No shell into a running VM

There is nothing to exec into. jerboa exec sends a signal; debugging goes through logs, stats and the serial console.

macOS is a development preview

It needs Apple Silicon and macOS 26 or newer, and the app is not yet signed by Apple.

Windows runs through WSL2

The daemon lives in a dedicated WSL2 distro. There is no native Windows virtualization.

Install

One installer ships the CLI and the daemon. Then build any Go, Node.js, Python or Rust project.