From 50f719525009739de45da130c562753c51689c5a Mon Sep 17 00:00:00 2001 From: Jerome Jaggi Date: Fri, 3 Jul 2026 18:42:33 +0200 Subject: [PATCH 1/5] docs: Add Release 11 (Metis) release notes Add a Releases section with a landing index and the Release 11 (Metis) release notes, covering the platform features (branching, checkpointing, custom filesystems and persistent volumes, custom network configuration, network shield and relay, and the plugin API) and the supporting tooling. Wire the Releases category and the /releases redirect into the Zudoku navigation. Signed-off-by: Jerome Jaggi --- pages/releases/index.mdx | 10 ++ pages/releases/r11-metis.mdx | 300 +++++++++++++++++++++++++++++++++++ zudoku.config.tsx | 10 ++ 3 files changed, 320 insertions(+) create mode 100644 pages/releases/index.mdx create mode 100644 pages/releases/r11-metis.mdx diff --git a/pages/releases/index.mdx b/pages/releases/index.mdx new file mode 100644 index 0000000..8aa02e6 --- /dev/null +++ b/pages/releases/index.mdx @@ -0,0 +1,10 @@ +--- +title: Releases +description: Release notes and changelog for Unikraft Cloud. +--- + +This section tracks all releases of Unikraft Cloud, including new features, improvements, and bug fixes. + +| Release | Date | Summary | +|---|---|---| +| [Release 11 — Metis](/releases/r11-metis) | 2026-07-03 | Branching and checkpointing, custom filesystems and persistent volumes, custom networking with network shield and relay, and a plugin API. | diff --git a/pages/releases/r11-metis.mdx b/pages/releases/r11-metis.mdx new file mode 100644 index 0000000..7df2399 --- /dev/null +++ b/pages/releases/r11-metis.mdx @@ -0,0 +1,300 @@ +--- +title: "Release 11: Metis" +description: Unikraft Cloud Release 11 (Metis) release notes. +--- +**Released:** 2026-07-03 + +--- + +{/* vale off */} + +Release 11 is a major step forward for the platform, and it comes jam-packed. Headlining it are advanced snapshotting capabilities — branching and checkpointing — alongside custom filesystems for persistent storage, and a plugin API that transparently extends a microVM with your own code. A sandbox plugin built on it is already available to enterprise customers. + +Also on the sandbox track — but useful for all use cases — is our new network shield. It sits between any microVM and the public Internet, filtering traffic and injecting tokens, credentials or secrets so they never have to live inside the microVM (read: agent) itself. The shield is implemented as a minimalist, scale-to-zero microVM of its own, so it is as strongly isolated as everything else you run — and, being a microVM, extremely flexible in what it can do (iptables, eBPF, and so on). + +All features in this release are available immediately to enterprise customers and are coming to the hosted platform very soon. From now on, we will publish public release notes once a month. Below, the release is split into platform features and the tooling that supports them. + +{/* vale on */} + +--- + +## Platform + +### Branching + +Branching clones an existing instance (microVM), including its full memory and volume state, by referencing a source instance in the `POST /v1/instances` call: + +```json +{ + "name": "my-branch", + "branch_from": { "name": "my-instance" } +} +``` + +As with creating an instance from a template, you can add ROMs, attach volumes, and configure services on the branch. +The source VM experiences at most a few milliseconds of downtime when you take a branch, rather than pausing during a copy. + +**Breaking changes:** None. +This is an additive capability. + +**Requirements and limitations:** Branching supports block-based volumes (for example, `ext4`). +Requires a valid license. + +**Why it matters:** Branching is the foundation for stateful instance workflows on the platform. +It enables fast, low-downtime cloning of live workloads for testing, scaling, and recovery. +It applies to many use cases, including launching sub-agents or branching large production databases to safely develop on them. + +**Learn more:** [Branching](/features/branching) + +### Checkpointing + +Checkpointing captures the state of a microVM (running or in any other state), including its full memory and volume state, as a named, restorable checkpoint. +You can take a checkpoint of a running instance without stopping it, keep a history of successive checkpoints, and create new instances from any checkpoint later on. + +Create checkpoints via `POST /v1/instances/checkpoints`: + +```json +{ + "name": "my-checkpoint", + "from": { "name": "my-instance" } +} +``` + +A checkpoint enters a `starting` state while the platform creates it, then transitions to a `checkpoint` state. +If you omit a name, the checkpoint inherits the instance name plus a random suffix. +The API provides a complete set of management endpoints: + +- **Per-instance history:** `GET /v1/instances/history?name=my-instance` +- **Per-checkpoint lineage:** `GET /v1/instances/checkpoints/history?name=my-checkpoint` +- **Checkpoint details:** `GET /v1/instances/checkpoints?name=my-checkpoint` +- **List all checkpoints:** `GET /v1/instances/checkpoints` +- **Delete:** `DELETE /v1/instances/checkpoints?name=my-checkpoint` +- **Patch** (delete-lock, tags, autokill): `PATCH /v1/instances/checkpoints` + +Checkpoints support an `autokill` property (`{ "time_ms": X }`) that removes a checkpoint automatically if you haven't loaded it within the given time window. +Deleting an instance that owns checkpoints doesn't remove those checkpoints. +You load a checkpoint by creating a new instance from it via `POST /v1/instances`, configuring services, extra volumes, and ROMs on the new instance as you would with branching and templates: + +```json +{ + "name": "my-new-instance", + "checkpoint": { "name": "my-checkpoint" } +} +``` + +Coming soon: fully rewindable VMs that you can rewind to an arbitrary checkpoint without spawning a new one. + +**Breaking changes:** None. +This is an additive capability. + +**Requirements and limitations:** Requires a valid license. +Checkpointing only works with block-based volumes (for example, `ext4`). +You load checkpoints by creating a new instance from them; in-place rewind of an instance to a previous checkpoint isn't part of this release. + +**Why it matters:** Checkpointing gives you low-latency, point-in-time recovery and reproducible starting states for running workloads. +This helps with debugging, experimentation, and rollback. + +**Learn more:** [Checkpoints](/features/checkpoints) + +### Custom filesystems and persistent volumes + +Unikraft Cloud supports defining custom filesystems with custom hooks for operations like format, mount, unmount, and delete. +This enables volumes that you can share across a cluster, and so persistent volumes for use cases such as running ephemeral agents whose state lives in volumes. +That state then stays available across the nodes or servers in a cluster, for example shared storage backed by S3 with a POSIX interface like JuiceFS provides. + +**Breaking changes:** None. +This is an additive capability. + +**Requirements and limitations:** None. + +**Why it matters:** Enables cluster-level, shared filesystem capabilities for agentic and other use cases. + +**Learn more:** [Volumes](/platform/volumes#filesystems) + +### Custom network configuration + +You can now create microVMs with several network interfaces and fully custom network configuration via `POST /v1/instances`: + +```json +{ + "network_interfaces": [ + { "name": "my-instance-private" }, + { "name": "my-instance-public", "ip": "192.168.0.1/30", "tap_name": "vpc0", "autoconfig": true } + ], + "gateway": "192.168.0.100", + "nameserver": "1.2.3.4" +} +``` + +The first interface is the **primary interface**: the `private_ip` that the instance returns always comes from it, and the proxy forwards traffic to the primary interface's IP. +If you omit `ip` and `tap_name`, the platform chooses a TAP device from its pool; you must specify both fields or neither. +Interface names are user-global rather than instance-local, so another instance can reference your interface as its relay. +If you omit `name`, the platform autogenerates it as `-ethX`, falling back to `eth-`. +`autoconfig` (default `true`) controls whether the guest kernel configures the interface or leaves it to the app/image, independent of the TAP device used. +An empty `"network_interfaces": [ {} ]` is valid and allocates one pool interface with an autogenerated name, the same as omitting the field. +When you don't specify `gateway` or `nameserver`, the platform derives them from the relevant interface's IP network. + +**Breaking changes:** None. +The controller detects whether the guest kernel supports the feature, so existing images and workloads keep working. + +**Requirements and limitations:** Up to 4 interfaces per instance. +Requires the latest `base-compat`, the `net_manager` permission, and a valid license. +This release doesn't support PATCH for network configuration. + +**Why it matters:** Custom network interfaces enable real VPC-style topologies, such as public/private separation and custom gateways and nameservers. +They also form the foundation that the network shield builds on, which makes them essential for secure sandbox networking. + +**Learn more:** [Custom network configuration](/features/custom-network-configuration) + +### Network shield and relay + +The network shield transparently inserts a shield between a microVM and the public Internet. +The shield filters traffic and can inject credentials or secrets for agentic and other use cases. +It relies on a relay feature that redirects all network traffic to and from a network interface toward another interface. +This lets you set up a gateway or proxy VM and configure its interface as the relay for another VM's interface via `POST /v1/instances`: + +```json +{ + "name": "my-sandbox", + "network_interfaces": [ + { "relay": { "name": "my-gateway-iface", "relay_dns": true } } + ] +} +``` + +Relay is a core part of the sandbox support in Unikraft Cloud. +A typical topology pairs a sandbox instance with a shield microVM that scans all inbound and outbound traffic and injects secrets, so the sandbox never has unfiltered network access and never holds any secrets itself. +All traffic passes over the relay, and several VMs can share a single relay. +Unikraft Cloud supports managed interfaces with custom TAP devices, and you don't need to enable VM-to-VM communication (which you wouldn't want in a sandbox setup anyway). +The relay can handle DNS requests, or the platform's default DNS server can answer them via `relay_dns` (default `true`), which simplifies setups that don't run a DNS server in the relay VM. +A guest acting as a relay should set `net.ipv4.ip_forward=1` and `rp_filter=0`. + +**Breaking changes:** None. +This is an additive capability built on the custom network configuration. + +**Requirements and limitations:** Requires the latest `ukp-networking` package and a reconfiguration of the firewall and TAP devices. +As part of the custom network configuration, that feature gates relay. + +**Why it matters:** Shield and relay make a genuinely secure sandbox possible. +They centralize traffic inspection and secret injection in a controlled gateway, which keeps untrusted workloads isolated from secrets and from unfiltered network access. +Because each shield runs as a separate microVM, every shield instance stays fully isolated from the others, so you get isolation for your main workload (such as sandboxes, browsers, and databases) and for the shield protecting it. + +**Learn more:** [Network shield and relay](/features/custom-network-configuration#network-shield-and-relay) + +### Plugin API + +The plugin API powers the native sandbox experience: a plugin runs a small HTTP server that accepts commands for execution in the VM, offers filesystem services, and more. +The mechanism is general and supports other plugin types as well. +Unlike running an HTTP server as a regular service, plugin HTTP access uses the same authentication as a normal API call, requires no service group, and talks directly to the instance/microVM. +When you enable scale-to-zero, the request wakes the instance, which stays up for the request's duration, exactly like a normal request. + +The plugin API loads plugins into an instance and exposes each plugin over an authenticated URL of the form `https://api..unikraft.cloud/v1/instances//plugins//*`. +The platform forwards everything after the plugin name (`*`) to the plugin as the URL. +You declare plugins at instance creation time via `POST /v1/instances`, where `config` accepts arbitrary JSON: + +```json +{ + "name": "my-instance", + "plugins": [ + { "name": "my-plugin", "image": "user/myplugin:latest", "config": {} } + ] +} +``` + +A plugin is a standard ROM image (a standard Unikraft Cloud feature; see the docs) with an executable named `init` in its root. +The platform loads and mounts it at `/uk/plugins/`, starts it, passes its `config` via STDIN, and passes an `--api_fd X` argument that carries the socket file descriptor it uses to accept connections. +The controller assigns the socket port on a best-effort basis within a configurable range (`--vmm-plugin-port-start`, default 20000; `--vmm-plugin-port-end`, default 29999), skipping ports already in use by the guest. +Plugin names can be up to 63 characters and contain only `a-z`, `A-Z`, `0-9`, `-`, and `_`. +The PATCH endpoint fully supports plugins, which load on the scale-to-zero, suspend, and restart cycle like ROMs, and which an instance inherits when you clone it via branching or checkpointing. + +**Breaking changes:** None. +This is an additive capability. + +**Requirements and limitations:** Requires the latest `base-compat` and a valid license. +You can load up to 8 plugins per instance. +Plugin unloading arrives in the next release. + +**Why it matters:** The plugin API delivers a powerful, native sandbox experience: in-VM command execution and filesystem services over an authenticated channel, without exposing an unauthenticated service. +It also provides a general extension point for custom in-instance functionality that applies to any use case. +Dashboard support for the plugin API is coming soon. + +**Learn more:** [Plugins](/features/plugins) + +--- + +## Tooling + +### Agent + +#### Image pruning + +The agent now automatically prunes unused images from disk. +When no running or stopped instance references an image any longer, the agent garbage-collects it to reclaim space; if you need the image again later, the agent pulls it on demand from the registry. + +**Breaking changes:** Images that you push directly to the [local registry](/cli/registries) now become eligible for pruning, so don't treat them as long-term storage. +Push images you want to keep to the global registry instead. + +**Requirements and limitations:** Pruning applies only to images that no instance currently uses. + +**Why it matters:** Prevents hosts from filling their disks over time in environments with frequent image rebuilds or updates, which reduces operational toil and avoids unexpected failures from exhausted storage. + +**Learn more:** [Unikraft Cloud documentation](https://unikraft.com/docs/introduction) + +#### Improved health checks + +The `/v1/healthz` endpoint now supports more health checks, including admin-defined checks for workflows like marking a node as not ready during upgrades or draining. +With root access, it can also include more metadata, such as version information and license status, to simplify remote inspection. + +**Breaking changes:** None. + +**Requirements and limitations:** The endpoint returns some fields only with elevated or root access. + +**Why it matters:** Makes it easier to automate operations and diagnose issues across a fleet using a single, scriptable health endpoint. + +**Learn more:** [Unikraft Cloud documentation](https://unikraft.com/docs/introduction) + +### CLI + +#### Follow logs on start and restart + +`unikraft` already supported following logs for instances that you create and start via `unikraft run`, but `unikraft start` and `unikraft restart` didn't. +This release adds `--follow` consistently across these commands. + +**Breaking changes:** None. + +**Requirements and limitations:** Log streaming depends on the platform's logging support for the instance. + +**Why it matters:** Removes a small but common workflow inconsistency and reduces friction when you check a start or restart. + +**Learn more:** [Unikraft Cloud documentation](https://unikraft.com/docs/introduction) + +### Dashboard + +#### Revamped dashboard + +A powerful product deserves a beautiful interface, and the dashboard now has a fully revamped one. + +You can now check real-time metrics for all your resources and inspect instance logs. +You can start and stop instances directly from the UI and manage your organization, including user management. + +Coming soon, you'll also be able to SSH directly into a particular instance, create and delete instances, and inspect the lifetime of an instance as you checkpoint or fork it. + +**Breaking changes:** None. + +**Requirements and limitations:** None. + +**Why it matters:** Improves usability today and sets up a stronger UI foundation, so future dashboard features can ship faster and more consistently. + +#### Online enterprise documentation + +Enterprise documentation has moved from a static, periodically distributed document to a centralized online docs portal for enterprise customers. + +**Breaking changes:** None. + +**Requirements and limitations:** Only enterprise customers can access it. + +**Why it matters:** Keeps documentation current, makes updates available immediately, and provides a single source of truth for enterprise operators. + +--- + +[Back to all releases](/releases) diff --git a/zudoku.config.tsx b/zudoku.config.tsx index 7a6a460..3cdb91f 100644 --- a/zudoku.config.tsx +++ b/zudoku.config.tsx @@ -573,6 +573,15 @@ const config: ZudokuConfig = { icon: "book-a", to: "https://unikraft.com/glossary", }, + { + type: "category", + label: "Releases", + icon: "tag", + items: [ + "/releases/index", + "/releases/r11-metis", + ], + }, ], search: { type: "pagefind", @@ -582,6 +591,7 @@ const config: ZudokuConfig = { { from: "/cli", to: "/cli/overview" }, { from: "/kraftfile", to: "/kraftfile/v0.7" }, { from: "/guides", to: "/guides/overview" }, + { from: "/releases", to: "/releases/index" }, ], apis: [ { From 9c39e5ce95bb02f57735f8005c6d1d55b002b617 Mon Sep 17 00:00:00 2001 From: Jerome Jaggi Date: Sun, 5 Jul 2026 23:20:48 +0200 Subject: [PATCH 2/5] docs: Add Release 10 (Themisto) release notes Add the Release 10 (Themisto) release notes covering the platform (instance lifecycle management, annotations, hotplug volumes, indefinite retention, TAP wake-up) and the supporting tooling (CLI v0.3, KraftKit v0.12.13, Kraftlet v0.5.0). Wire the release into the index table and the Zudoku navigation. Signed-off-by: Jerome Jaggi --- pages/releases/index.mdx | 1 + pages/releases/r10-themisto.mdx | 326 ++++++++++++++++++++++++++++++++ zudoku.config.tsx | 1 + 3 files changed, 328 insertions(+) create mode 100644 pages/releases/r10-themisto.mdx diff --git a/pages/releases/index.mdx b/pages/releases/index.mdx index 8aa02e6..f852d81 100644 --- a/pages/releases/index.mdx +++ b/pages/releases/index.mdx @@ -8,3 +8,4 @@ This section tracks all releases of Unikraft Cloud, including new features, impr | Release | Date | Summary | |---|---|---| | [Release 11 — Metis](/releases/r11-metis) | 2026-07-03 | Branching and checkpointing, custom filesystems and persistent volumes, custom networking with network shield and relay, and a plugin API. | +| [Release 10 — Themisto](/releases/r10-themisto) | 2026-06-05 | Instance lifecycle management, annotations, hotplug volumes, indefinite retention, TAP wake-up, new `unikraft api` CLI, EROFS rootfs, ROM support, and Kraftlet CSI integration. | diff --git a/pages/releases/r10-themisto.mdx b/pages/releases/r10-themisto.mdx new file mode 100644 index 0000000..66ce429 --- /dev/null +++ b/pages/releases/r10-themisto.mdx @@ -0,0 +1,326 @@ +--- +title: "Release 10: Themisto" +description: Unikraft Cloud Release 10 (Themisto) release notes. +--- +**Released:** 2026-06-05 + +--- + +{/* vale off */} + +Release 10 focuses on instance lifecycle management and observability. New capabilities include runtime user management, instance annotations, hotpluggable volumes for scale-to-zero instances, indefinite instance retention with post-mortem metrics, and the ability to wake VMs from TAP device traffic. On the tooling side, the CLI gains a new `unikraft api` passthrough and EROFS rootfs by default, while Kraftlet picks up full CSI integration and ROM-based ephemeral volumes. + +{/* vale on */} + +--- + +## Platform + +### Image tag response format change + +The `GET /v1/images` and `GET /v1/images/list` endpoints now return only the actual OCI tag. +For an image such as `oci://unikraft.io/user/image:latest`, the response previously contained `user/image:latest` and now contains just `latest`. +Clients that parse the `tag` field should be updated accordingly. + +### Retained instance state renamed + +The lifecycle state that an instance enters once it has been logically removed but is still being retained has been renamed from `dead` to `deleted`. +Any monitoring, automation, or filtering logic that matches on the previous state name must be updated. + +### User management at runtime via userdb + +A new user database (`userdb`) makes it possible to manage users at runtime rather than only at startup. +As part of this work, internal database entry replacements were made atomic, improving overall robustness. +The previous "no authorization" mode has been removed; deployments must now run with authorization enabled. + +### Instance annotations + +Instances can now carry user-defined annotations, which can additionally be included in the instance log output. +This makes it easier to correlate instance behavior with deployment-specific metadata such as environment, tenant, or release identifiers. + +### Hotplug volumes for scale-to-zero and template-derived instances + +New volumes can now be hotplugged to instances when they go through scale-to-zero cycles, and volumes can be added to instances that were created from templates. +This allows storage configuration to evolve over the lifetime of an instance without having to recreate it. + +### Indefinite retention of instances + +Retained instances can now be kept indefinitely instead of being subject to a time-based expiration. +This is useful for keeping post-mortem state available for longer investigation windows. + +The instance `DELETE` endpoint now accepts a `dont_retain` flag that removes a retained instance immediately instead of keeping it around for the configured retention window. +This gives operators a direct way to reclaim resources held by retained instances. + +### Metrics endpoint available for retained instances + +The `/v1/instances/metrics` endpoint can now be queried for retained instances. +Operators can continue to export metrics for instances that have been removed but are still being retained, which is useful for debugging and accounting. + +### Image pull policy forwarding + +The image pull policy configured in the API is now forwarded to the host agent. +This allows eliminating image pull latency when the `if_not_present` policy is used together with background image updates configured in the host agent. + +### Merge image default environment with instance environment + +When starting an instance, the environment variables defined as defaults on the image are now merged with any instance-level environment variables, rather than the instance-level variables fully replacing the defaults. +This change also fixes a problem where environment variables were not properly escaped. + +### Image fetch errors propagated to the proxy + +Image fetch failures are now propagated to the proxy layer. +Clients triggering an instance via the proxy receive a more meaningful response when the underlying image cannot be pulled, instead of a generic failure. + +### Wake VMs from TAP device traffic + +Instances can now be woken up by incoming traffic on their TAP device, broadening the set of wake-up sources beyond the existing trigger mechanisms. +This allows private VM instances without a service group to have scale-to-zero configured and wake up when needed. + +### Configurable database storage location + +A new `--db-path` option lets operators choose where the platform stores its databases. +This makes it easier to place the databases on dedicated storage, separate from logs or other state. + +### Bug fixes + +- A race in the snapshot abort path could trigger a false assertion and leave an instance stuck in the `STOPPING` state. +- Snapshot retries after abort now proceed correctly. +- Race conditions during snapshot teardown when the VMM process died have been fixed. +- Snapshots are now consistently cleaned up as part of orderly shutdown. +- The dynamic worker pool used by the snapshot subsystem has been replaced with a fixed-size pool, eliminating scaling-related instability under bursty workloads. +- An instance that had been through a restart cycle could crash the controller when subsequently stopped. +- Draining no longer inadvertently clears the delete-on-stop property. +- The suspend endpoint now handles instances that are still waiting on start prerequisites. +- API wait operations now complete reliably for scale-to-zero instances. +- The scale-to-zero notification path can no longer be stalled by guest behavior. +- TAP device reuse is now gated to prevent misrouted connections when the proxy timeout exceeds interface retention time. +- Volume clone deadlock and starvation issues have been resolved. +- External heap references are no longer lost during the VMDB v0.7 to v0.8 upgrade. +- Heap objects are now retained on the correct heap during imgdb upgrades. +- A startup-time crash related to the VM message queue has been fixed. +- Two separate race conditions in the image resolution path have been eliminated. +- A retry of a previously failed image request no longer results in a crash. +- A use-after-free condition has been fixed in the autoscale cleanup path. +- Building inline ROMs now works on Debian 11. +- The Prometheus metrics endpoint now reports stop times correctly instead of start times. +- Listings with `order` but without `sortby` are now sorted correctly and pagination no longer skips objects. +- Negative boot time is no longer reported for boots exceeding approximately 34 minutes. +- The VMM now re-sends the shutdown signal if the first one arrives before the guest is ready, preventing instances from hanging in `STOPPING`. +- The `cputime` metric now accurately reflects CPU time consumed by the instance. +- Internal service groups can now be reached from other instances via the proxy for both TCP and UDP. +- CoreDNS has been upgraded from v1.13.2 to v1.14.3. +- The `ukpdns` plugin in CoreDNS now uses persistent connections, reducing DNS resolution latency under load. + +--- + +## Tooling + +### CLI + +#### New `unikraft api` subcommand + +`unikraft api ` issues an authenticated HTTP request to the Unikraft Cloud API, reusing the current profile, default metro, and credentials. +It is intended for endpoints that do not yet have a dedicated subcommand, and for exploration and scripting. + +```sh +# List instances in the default metro +unikraft api /v1/instances + +# Inspect a specific instance +unikraft api /v1/instances/abc123-...-def456 + +# Create a 256MB volume in fra +unikraft api /v1/volumes --metro fra -d '{"name":"data","size_mb":256}' + +# POST a request body from a file or stdin +unikraft api /v1/volumes -d @volume.json +cat volume.json | unikraft api /v1/volumes -d @- + +# Delete an instance +unikraft api /v1/instances/abc123-...-def456 -X DELETE +``` + +#### EROFS rootfs by default + +`unikraft build` now produces EROFS root filesystems by default. +EROFS images are smaller and faster to mount than the CPIO archives used previously, which translates to lower cold-start latency and reduced per-image storage cost. + +The selection is driven by the runtime's advertised feature flags: if every target platform reports EROFS support, EROFS is used; otherwise the builder transparently falls back to CPIO. +Existing Kraftfiles continue to work without changes. + +#### Kraftfile schema updates + +Two changes have landed in the v0.7 Kraftfile schema. + +`rootfs.format` no longer defaults to `cpio` at parse time. +Previously, a `rootfs` without an explicit `format` was rewritten to `format: cpio` by the parser. +The parser now leaves the field empty and lets the tooling pick a format based on the target runtime's advertised capabilities. +Set `format:` explicitly if you need to pin one. + +```yaml +spec: v0.7 +rootfs: + source: ./rootfs + # format: cpio # set explicitly to pin; previously implied +``` + +New optional `dockerfile:` field on `rootfs.source`. +A Dockerfile-backed rootfs can now point at a Dockerfile separately from its build context, matching the behaviour of `docker build -f`. + +```yaml +spec: v0.7 +rootfs: + source: + type: dockerfile + path: . + dockerfile: ./custom/path/Dockerfile +``` + +#### ROM support + +ROMs are read-only image volumes that can be shared between many instances at very low overhead. +The CLI can now build them, attach them at instance creation time, and edit them on existing instances. + +```sh +# Attach a ROM image at /rom on a new instance +unikraft instance create \ + --name demo \ + --metro fra \ + --image nginx:latest \ + --rom image=myuser/my-rom:latest,at=/rom,name=docs + +# Attach an inline ROM built from a local directory +unikraft instance create \ + --name demo \ + --metro fra \ + --image nginx:latest \ + --rom dir=./mydata,at=/rom + +# Add a ROM to an existing instance +unikraft instance edit demo --rom image=myuser/my-rom:latest,at=/rom2 +``` + +ROMs are also surfaced as fields on `unikraft instance get`/`list` under `roms.*.{name,image,dir,at}`. + +#### `deleted` instance state + +The CLI now understands the new `deleted` lifecycle state for instances that have been logically removed but are still being retained. +They appear in `unikraft instance list` and can be filtered for explicitly. + +```sh +unikraft instance list --filter 'state==deleted' +``` + +#### Volume access modes + +`unikraft volume create` now accepts an `--access-mode` flag that controls whether a volume can be attached to multiple instances at once. + +```sh +# Read-write, single attachment (default) +unikraft volume create --name data --size 10GiB --access-mode rwo + +# Read-only, may be attached to many instances +unikraft volume create --name assets --size 1GiB --access-mode rox + +# Read-write, may be attached to many instances +unikraft volume create --name shared --size 1GiB --access-mode rwx +``` + +#### `--rm` flag on `unikraft instance create` + +`unikraft instance create --rm` marks the VM to be deleted automatically once it exits. +This is the Unikraft Cloud equivalent of `docker run --rm` and is the preferred form for one-shot and CI workloads. + +```sh +unikraft instance create \ + --name oneshot \ + --metro fra \ + --image my-job:latest \ + --rm +``` + +#### `idle` scale-to-zero policy + +`--scale-to-zero` now accepts `policy=idle` in addition to `on` and `off`. +Idle instances are scaled down after `cooldown-time` of no activity, without requiring an explicit stateful/stateless distinction. + +```sh +unikraft instance create \ + --name web \ + --metro fra \ + --image nginx:latest \ + --scale-to-zero policy=idle,cooldown-time=30000 +``` + +#### Insecure registries + +`unikraft build` and `unikraft images` now accept `--insecure` to opt into HTTP or unverified-TLS connections to specific registries, for use with internal mirrors and self-signed deployments. + +```sh +unikraft build . --output my-org/my-app:latest --insecure registry.internal +unikraft images pull my-org/my-app:latest --insecure +``` + +#### Bug fixes + +- `unikraft build` no longer drops or renames dotfiles such as `.config` from the rootfs. +- The builder now accepts custom Dockerfile names via `-f`. +- Image references targeting Docker Hub under the implicit `docker.io/library` namespace are now canonicalized correctly, fixing push failures. +- When the platform's new listing endpoint is unavailable, the CLI falls back to the previous endpoint instead of failing. + +### KraftKit + +#### Kraftfile schema v0.7 + +KraftKit picks up the v0.7 schema changes: `rootfs.format` is no longer defaulted at parse time, and a new optional `dockerfile:` field can point at a custom Dockerfile path. + +#### Fetch images from per-metro image stores + +`kraft cloud image list` and image-pull flows now consult per-metro image stores in addition to the global registry. +When a metro has already cached an image locally, the pull resolves against it directly, shortening cold-start image pulls for clients colocated with the metro. + +```sh +# Lists images visible in the fra metro, including its local store +kraft cloud image list --metro fra +``` + +#### Bug fixes + +- Rollout image names are now sanitized before submission, and the `--insecure` flag is honored during the intermediate copy step of a rollout. +- KraftKit no longer requires KraftKit-specific annotations on the images it consumes, so any standards-compliant OCI image can be used as a source. + +### Kraftlet + +#### CSI integration + +Kraftlet now integrates with the Kubernetes CSI to provision and attach volumes from arbitrary storage backends to Unikraft Cloud instances. +Kraftlet stages volumes by calling the appropriate CSI plugin based on the PVC's storage class, then publishes them to the VM via Unikraft Cloud managed volumes. + +The Helm chart now exposes the CSI endpoint and supports setting the required node annotations. + +```yaml +# values.yaml +csi: + endpoint: unix:///var/lib/kubelet/plugins/csi.example.com/csi.sock +nodeAnnotations: + volumes.kubernetes.io/controller-managed-attach-detach: "true" +``` + +#### Ephemeral volumes as ROMs + +`configMap`, `secret`, and projected volumes are now mounted as inline ROMs instead of going through the previous import flow. +Pod startup no longer has to wait for an import instance to populate the volume contents, which reduces start time for pods that mount ConfigMaps or Secrets. + +#### Resource tagging + +All Unikraft Cloud resources created by Kraftlet are tagged with their origin, including the Kraftlet node name, originating Kubernetes namespace and resource name, and CSI plugin and storage class where applicable. +This allows attributing Unikraft Cloud resources back to their Kubernetes owners without maintaining a separate mapping. + +#### Custom node annotations + +Kraftlet can advertise arbitrary annotations on its Kubernetes node object, configured through the Helm chart. +This underpins the CSI controller-managed-attach annotation and allows operators to attach cluster-side metadata to the Kraftlet node. + +--- + +[Back to all releases](/releases) diff --git a/zudoku.config.tsx b/zudoku.config.tsx index 3cdb91f..b478e11 100644 --- a/zudoku.config.tsx +++ b/zudoku.config.tsx @@ -580,6 +580,7 @@ const config: ZudokuConfig = { items: [ "/releases/index", "/releases/r11-metis", + "/releases/r10-themisto", ], }, ], From 2642578f160584f60e978e30f15c72746018dbed Mon Sep 17 00:00:00 2001 From: Jerome Jaggi Date: Sun, 5 Jul 2026 23:28:41 +0200 Subject: [PATCH 3/5] =?UTF-8?q?docs:=20List=20releases=201=E2=80=939=20in?= =?UTF-8?q?=20the=20releases=20index?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add releases 1 (Ganymede) through 9 (Leda) as unlinked table rows with a note that public release notes begin with Release 10. Signed-off-by: Jerome Jaggi --- pages/releases/index.mdx | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/pages/releases/index.mdx b/pages/releases/index.mdx index f852d81..129aa66 100644 --- a/pages/releases/index.mdx +++ b/pages/releases/index.mdx @@ -9,3 +9,14 @@ This section tracks all releases of Unikraft Cloud, including new features, impr |---|---|---| | [Release 11 — Metis](/releases/r11-metis) | 2026-07-03 | Branching and checkpointing, custom filesystems and persistent volumes, custom networking with network shield and relay, and a plugin API. | | [Release 10 — Themisto](/releases/r10-themisto) | 2026-06-05 | Instance lifecycle management, annotations, hotplug volumes, indefinite retention, TAP wake-up, new `unikraft api` CLI, EROFS rootfs, ROM support, and Kraftlet CSI integration. | +| Release 9 — Leda | | — | +| Release 8 — Ananke | | — | +| Release 7 — Carme | | — | +| Release 6 — Lysithea | | — | +| Release 5 — Amalthea | | — | +| Release 4 — Europa | | — | +| Release 3 — Io | | — | +| Release 2 — Callisto | | — | +| Release 1 — Ganymede | | — | + +Release notes for versions prior to Release 10 were distributed to customers directly. Public release notes begin with Release 10. From 9e15e2af0c6c0774a4d5614e3f6facda77275433 Mon Sep 17 00:00:00 2001 From: Jerome Jaggi Date: Sun, 5 Jul 2026 23:37:43 +0200 Subject: [PATCH 4/5] docs: Move prior-releases note to intro section Signed-off-by: Jerome Jaggi --- pages/releases/index.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/pages/releases/index.mdx b/pages/releases/index.mdx index 129aa66..071ebe6 100644 --- a/pages/releases/index.mdx +++ b/pages/releases/index.mdx @@ -4,6 +4,7 @@ description: Release notes and changelog for Unikraft Cloud. --- This section tracks all releases of Unikraft Cloud, including new features, improvements, and bug fixes. +Release notes for versions prior to Release 10 were distributed to customers directly. Public release notes begin with Release 10. | Release | Date | Summary | |---|---|---| @@ -18,5 +19,3 @@ This section tracks all releases of Unikraft Cloud, including new features, impr | Release 3 — Io | | — | | Release 2 — Callisto | | — | | Release 1 — Ganymede | | — | - -Release notes for versions prior to Release 10 were distributed to customers directly. Public release notes begin with Release 10. From 1565f46deb7269809b538b83284b3673e2929d0d Mon Sep 17 00:00:00 2001 From: Jerome Jaggi Date: Sun, 5 Jul 2026 23:38:43 +0200 Subject: [PATCH 5/5] docs: Remove bug fixes from Release 10 notes Signed-off-by: Jerome Jaggi --- pages/releases/r10-themisto.mdx | 42 --------------------------------- 1 file changed, 42 deletions(-) diff --git a/pages/releases/r10-themisto.mdx b/pages/releases/r10-themisto.mdx index 66ce429..80c82d4 100644 --- a/pages/releases/r10-themisto.mdx +++ b/pages/releases/r10-themisto.mdx @@ -81,36 +81,6 @@ This allows private VM instances without a service group to have scale-to-zero c A new `--db-path` option lets operators choose where the platform stores its databases. This makes it easier to place the databases on dedicated storage, separate from logs or other state. -### Bug fixes - -- A race in the snapshot abort path could trigger a false assertion and leave an instance stuck in the `STOPPING` state. -- Snapshot retries after abort now proceed correctly. -- Race conditions during snapshot teardown when the VMM process died have been fixed. -- Snapshots are now consistently cleaned up as part of orderly shutdown. -- The dynamic worker pool used by the snapshot subsystem has been replaced with a fixed-size pool, eliminating scaling-related instability under bursty workloads. -- An instance that had been through a restart cycle could crash the controller when subsequently stopped. -- Draining no longer inadvertently clears the delete-on-stop property. -- The suspend endpoint now handles instances that are still waiting on start prerequisites. -- API wait operations now complete reliably for scale-to-zero instances. -- The scale-to-zero notification path can no longer be stalled by guest behavior. -- TAP device reuse is now gated to prevent misrouted connections when the proxy timeout exceeds interface retention time. -- Volume clone deadlock and starvation issues have been resolved. -- External heap references are no longer lost during the VMDB v0.7 to v0.8 upgrade. -- Heap objects are now retained on the correct heap during imgdb upgrades. -- A startup-time crash related to the VM message queue has been fixed. -- Two separate race conditions in the image resolution path have been eliminated. -- A retry of a previously failed image request no longer results in a crash. -- A use-after-free condition has been fixed in the autoscale cleanup path. -- Building inline ROMs now works on Debian 11. -- The Prometheus metrics endpoint now reports stop times correctly instead of start times. -- Listings with `order` but without `sortby` are now sorted correctly and pagination no longer skips objects. -- Negative boot time is no longer reported for boots exceeding approximately 34 minutes. -- The VMM now re-sends the shutdown signal if the first one arrives before the guest is ready, preventing instances from hanging in `STOPPING`. -- The `cputime` metric now accurately reflects CPU time consumed by the instance. -- Internal service groups can now be reached from other instances via the proxy for both TCP and UDP. -- CoreDNS has been upgraded from v1.13.2 to v1.14.3. -- The `ukpdns` plugin in CoreDNS now uses persistent connections, reducing DNS resolution latency under load. - --- ## Tooling @@ -261,13 +231,6 @@ unikraft build . --output my-org/my-app:latest --insecure registry.internal unikraft images pull my-org/my-app:latest --insecure ``` -#### Bug fixes - -- `unikraft build` no longer drops or renames dotfiles such as `.config` from the rootfs. -- The builder now accepts custom Dockerfile names via `-f`. -- Image references targeting Docker Hub under the implicit `docker.io/library` namespace are now canonicalized correctly, fixing push failures. -- When the platform's new listing endpoint is unavailable, the CLI falls back to the previous endpoint instead of failing. - ### KraftKit #### Kraftfile schema v0.7 @@ -284,11 +247,6 @@ When a metro has already cached an image locally, the pull resolves against it d kraft cloud image list --metro fra ``` -#### Bug fixes - -- Rollout image names are now sanitized before submission, and the `--insecure` flag is honored during the intermediate copy step of a rollout. -- KraftKit no longer requires KraftKit-specific annotations on the images it consumes, so any standards-compliant OCI image can be used as a source. - ### Kraftlet #### CSI integration