Zudoku
Use Cases

Build and Test Environments

Give every build or test job its own microVM. Start your full toolchain from a snapshot in milliseconds, and inject that job's code at boot time.

Start chunky environments fast

Pack the whole environment (compilers, deps, warm caches) into a template: a snapshot with all that state already initialized. Size stops mattering.

boots in < 10 ms
Run as many as you need

Run thousands of instances with minimal memory footprints on a platform built for scale, all on the same server.

100K+ microVMs / server
Inject the code to build, instantly

The code under test arrives as a ROM, a small read-only image mounted at start. Same environment, different payload per job, no rebuild.

no image rebuild
Base image

Your Dockerfile: toolchain, deps, caches

snapshot once
Template

Heavy initialisation done once, booted and frozen

< 10 ms each
+ ROM per job
build env
rom: pr-482
build env
rom: pr-483
test env
rom: nightly
...thousands more, scaled to zero when idle
One base image, one template, one small ROM per job. Everything right of the template happens in milliseconds.

Watch the recording to see a build environment snapshotted into a template, then two different builds injected as ROMs with 6 ms cold starts from both.


Under the hood

The platform features this use case is built on.

Pre-initialised snapshots let you do the heavy initialisation once, save the state, and start new instances from it, cutting startup to milliseconds.

Read-only blobs mounted on a VM. Combined with templates, they carry the per-job code onto each instance created from the template.

The instance shuts down when no work is running and comes back in milliseconds on the next request. You pay only for what you use.

Run your first build environment now

Sign up to Unikraft Cloud and follow the guide to run your first build environment

Last modified on