Release 12: Thebe
Released: 2026-08-04
Release 12 introduces GPU support for enterprise customers, shared instance templates across nodes, and a set of image management features including pinning, strict authorization, and pull timeouts. On the tooling side, the dashboard adds user invitations and richer instance and volume pages, and Kraftlet gains CNI plugin support.
Platform
GPU support
The platform now supports NVIDIA GPUs.
You select the instance type and GPU count when creating an instance via POST /v1/instances:
Code
type can be micro (default) or full.
Adding "gpus": 1 requests a GPU for the instance.
The platform picks a free GPU from the host and keeps it assigned for the instance's entire lifetime, including while it isn't running.
The platform releases the GPU when you delete the instance.
Running GPU workloads requires a guest kernel built with NVIDIA driver support, and the host must allow GPU passthrough.
Breaking changes: Instances default to micro, so existing workloads aren't affected.
Requirements and limitations: GPU support is in its first iteration.
At most one GPU per instance, and selecting a specific GPU isn't yet possible.
Block-based volumes work, but virtiofs volumes don't.
GPU VMs report as RUNNING immediately and forward network traffic regardless of whether the guest is listening.
Requires a valid license.
GPU snapshots are on the roadmap for the next release.
Enterprise only.
Shared instance templates
Instance templates used to be node-local: every controller had to build its own copy before cloning instances from it. You can now publish templates to a directory shared between controllers:
Code
With this option, the node publishes every named template it creates as a self-contained bundle. The export runs in the background, so the request returns as soon as the template is ready locally. A bundle carries the template, its dependencies (volumes, ephemeral images, parent templates), the memory snapshot, and the volume files. The importing node pulls registry images by address as usual.
Referencing a template by name now consults the shared directory.
When POST /v1/instances names a template that isn't present locally, the platform imports the newest matching bundle.
The platform replaces an existing local template when a newer bundle is available.
Templates key on name and owner, so the platform only imports a bundle for the user that exported it.
The platform versions bundles rather than overwriting them, and readers select the newest version.
--vm-template-gc-threshold-s (default 6h) sets how long the platform retains older versions after a new export.
--vm-template-recheck-interval-s (default 10s) throttles how often the platform checks the directory for updates.
Requirements and limitations: All nodes must see the same directory (for example, a shared network filesystem) and know the same users. The platform only exports named, non-ephemeral, fully converted templates with block-based volumes. Reflink support (XFS) is strongly recommended for performance.
Why it matters: Building a template is expensive. You can now build a template once and have it materialize on every other node on first reference. Scaling out to a fresh node no longer means a cold boot-and-snapshot cycle, and rolling out a new version is a single export.
Enterprise only.
Image pinning
Two new endpoints, POST /v1/images and DELETE /v1/images, let you pull an image and pin it to a node ahead of time:
Code
timeout_s lets you wait until the image is ready.
If the platform can't pull the image, the API response contains the underlying error.
GET /v1/images now also reports the state of each image:
Code
state is either pending (the platform is pulling it) or ready (usable).
persistent is true for pinned or operator-defined images.
Pinned images behave like operator-defined images, but you define them at runtime.
The platform doesn't release either type automatically when no longer in use.
You unpin an image with DELETE /v1/images?uuid=X.
Requirements and limitations: Requires the image_manager permission.
You must provide timeout_s.
Why it matters: Pinning turns image availability into something you control explicitly. Operators running many regions can pre-stage a new image version everywhere and only then switch traffic to it. This removes on-demand pulls from the critical path of starting an instance.
Enterprise only.
Strict image authorization
The platform caches image access permissions per user, so referencing the same image twice normally triggers only a single access check. For customers who operate their own registry with distinct registry users behind a single platform user, one authorized user's access can leak to another.
The new controller option --images-always-authorize closes this gap by requiring valid credentials every time you specify an image.
Breaking changes: None by default.
The option is opt-in.
When enabled, you can only use the never pull policy with pinned or operator-defined images.
Enterprise only.
Image pull timeout
Image requests now have a timeout, configurable with --images-request-timeout-s (default 60 seconds, 0 disables it).
On timeout, the instance moves to STOPPED.
Breaking changes: Instances that would hang in STARTING now end up in STOPPED after 60 seconds by default.
Why it matters: A failed pull now surfaces as a terminal state instead of a stuck instance. This lets error handling upstream react rather than waiting on a request that won't complete.
Enterprise only.
Image request merge control
When an image isn't yet in READY state and you reference it with differing credentials, each distinct reference produces its own request.
This release raises the per-image limit on parallel requests from 16 to 64.
A new option on the image object controls whether a reference merges with existing ones:
Code
Breaking changes: merge_requests defaults to enabled, which differs from the previous behavior.
Requirements and limitations: Setting merge_requests requires the image_manager permission.
Enterprise only.
Tooling
Heartbeat signals
Licensed Unikraft Cloud Platform installations now report regular health information to the central control plane. This currently includes simple, timestamped health data about the system.
Enterprise only.
Improved image pruning reliability
Image pruning (introduced in Release 11) keeps disk space usage down, but a few configurations could cause unexpected behavior. This release fixes those edge cases.
Enterprise only.
Dashboard
Organization user invitations
Organization admins can now invite new team members directly from the dashboard. Create an invite link for a new admin or member and share it through your preferred channel.
Improved instance and volume pages
The instance and volume pages now show more information, making it faster to diagnose errors and understand the scale of your resources at a glance.
Kraftlet
Kraftlet is the Unikraft Cloud integration for Kubernetes, allowing you to run microVMs as Kubernetes pods.
CNI plugin support
Kraftlet now supports Container Network Interface (CNI) plugins for configuring the networking stack of Unikraft-backed pods. This allows integration with different networking solutions from vendors like AWS, Tigera, and Isovalent.
A separate component, remote-cni, allows invoking CNI plugins via a gRPC service when Kraftlet isn't collocated with the platform.
Enterprise only.