Release 12 “Thebe”: GPUs and Better Image Control

Release 12 adds NVIDIA GPU support. You can now attach a GPU to an instance and run GPU-accelerated inference or an agent driving a headful browser on the same platform, through the same API, as everything else you host with us.

The second theme is giving users more control over images. Pinning lets you pull and hold an image on a node ahead of time; strict authorization makes shared private registries safe for many tenants; and pull timeouts turn hung pulls into a state your automation can react to. Image availability becomes something you decide rather than hope for at start time.

Instance templates also stop being node-local: build one once and it shows up across the whole cluster.

And the dashboard gets a big update. Organizations can now invite their own team members, with no ticket to us required, and the instance and volume pages show far more detail, so you can diagnose problems and size up your resources without leaving the dashboard. Licensed installations report health signals to our control plane, so what you see about your nodes is accurate and current.

Everything below is available immediately to enterprise customers; the dashboard improvements are already live for everyone on the hosted platform. Sign up here to get early notice of future releases.

Compute

R12 brings GPUs to the platform. It also makes the most expensive thing you build on a node (a template) portable across all of them.

NVIDIA GPU support (Enterprise)

You can now attach an NVIDIA GPU to an instance and run GPU-accelerated inference or an agent driving a headful browser next to everything else you host with us. Ask for one when creating the instance:

{
  "name": "my-first-gpu-instance",
  "type": "full",
  "gpus": 1,
  ...
}

Adding "gpus": 1 requests a GPU, and the platform picks a free one from the GPUs made available on the host. A GPU stays assigned to its instance for the instance’s entire lifetime (including while it is not running) and is released when the instance is deleted. GPU workloads need a guest kernel built with NVIDIA driver support, and the host must be configured for GPU passthrough. GPU support requires the latest kernel and a valid license.

You can run GPU VMs on the same box as, and alongside, the standard Unikraft microVMs you know and love. Next on the roadmap are GPU snapshots, which hand a GPU between suspended and resumed instances so that GPU workloads can eventually scale to zero too.

Shared instance templates (Enterprise)

Building an instance template (think a booted, snapshotted instance plus its volumes) is expensive, and a template configured by hand, from the inside, could not be reproduced on another node at all. Until now, that cost was paid once per node. Templates can now be published to a directory shared between controllers, and any node that references one by name picks it up automatically:

ukpd --vm-shared-template-dir /mnt/shared/templates ...

With the option set, every named template a node creates is published there as a self-contained, versioned bundle (snapshot, volumes, and dependencies included); the export runs in the background. When another node references the template by name, the newest bundle is imported automatically, and a newer version rolls out the same way.

Scaling out to a fresh node no longer means a cold boot-and-snapshot cycle; the same template, byte for byte, shows up on first reference. Rolling out a new version across the whole cluster is a single export.

Images

Four changes with one goal: take the registry off the critical path of starting an instance, and give you explicit control where the platform used to decide for you.

Image pinning (Enterprise)

When an image is pulled on demand at instance start, a slow or unreachable registry becomes your problem at the worst possible moment. Pinning changes that: pull an image onto a node ahead of time, hold it there, and know it is ready before anything depends on it. The prime use case is rollouts: pre-stage a new version across every region, confirm it is ready, and only then switch traffic to it.

Two new endpoints, POST /v1/images and DELETE /v1/images, do exactly that:

{
  "url": "user/image:latest",
  "timeout_s": 60
}

The endpoint accepts the same image object used everywhere else in the API (credentials, headers, pull_policy), and timeout_s lets you wait until the image is ready. GET /v1/images now reports each image’s state, pending or ready, so a rollout script can tell what is already usable.

A pinned image is never released behind your back: it stays on the node until you unpin it with DELETE /v1/images, which hands it back to the node’s normal pruning lifecycle.

Tag handling was overhauled to match: for pinned and operator-defined images, a tag is only invalidated once the replacement has already been pulled onto the node successfully, so a flaky registry connection no longer takes a working image with it.

Strict image authorization (Enterprise)

This one exists for a specific setup: your own private registry, with many independent registry identities behind a single platform user. Because access permissions are cached per platform user, one tenant’s authorized access could effectively be reused by another. A second request could omit or falsify credentials and still reach the image.

The new opt-in controller option --images-always-authorize closes this: every image reference must carry valid credentials and is checked with the registry, so revoked permissions are caught as well. Each tenant must prove access on its own credentials, so a single platform user can front many registry identities without leaking access between them.

Image pull timeout (Enterprise)

A pull that never answers used to strand an instance in STARTING indefinitely. Image requests now time out (60 seconds by default, configurable with --images-request-timeout-s) and move the instance to STOPPED.

A failed pull now surfaces as a terminal state instead of a stuck instance, so error handling upstream can react, for example by tearing down a JIT service, instead of waiting on a request that will never complete.

Image request merge control (Enterprise)

Workloads that authenticate with short-lived, per-request credentials (JWTs, say) could previously flood an image with parallel pull requests, one per credential set, crowding everyone else out. References are now merged with existing requests by default, and a new option on the image object lets clients that need separate authorization paths opt out:

{
  "url": "...",
  "merge_requests": false
}

merge_requests defaults to enabled (a change from the previous behavior), and setting it requires the image_manager permission.

Distinct users referencing the same image no longer contend with each other, and the per-image limit on parallel requests has been raised from 16 to 64.

Platform & Tooling

Rounding out R12: a dashboard your whole team can join, richer resource pages, health reporting to the hosted dashboard, and CNI networking for Kraftlet.

Invite your team to the dashboard (All customers)

Organizations can now invite additional users themselves: create an invite link for a new admin or member and share it however you like. No more asking the Unikraft team to add people for you. Only organization admins can create invites.

Improved instance & volume pages (All customers)

The instance and volume pages now show much more detail, so you can diagnose errors and size up your resources without building custom visualizations.

Heartbeat signals (Enterprise)

Licensed platform installations now report regular health information to our central control plane (currently simple, timestamped health signals), so the hosted dashboard shows current, accurate information about the health and reachability of your nodes. The control plane at controlplane.unikraft.cloud must be reachable.

CNI plugins for Kraftlet (Enterprise)

The Container Network Interface (CNI) is how Kubernetes configures pod networking, with plugins from vendors like AWS, Tigera, and Isovalent. Kraftlet, our Kubelet for unikraft-backed pods, now supports invoking CNI plugins and creating instances with custom network interfaces, so it is fully compatible with the networking layer of your cluster. And because Kraftlet need not be collocated with the platform, a separate component, remote-cni, invokes CNI plugins via a gRPC service.

Unikraft-backed pods can now use whatever networking solution your Kubernetes cluster already runs, one of the most requested capabilities in customer conversations.

A sneak preview of what’s next

A taste of what Release 13 has in store, coming in about 4 weeks:

GPU snapshotting — A GPU handed between suspended and resumed instances, to ensure the GPU is fully utilized.

Checkpoint rewind — Checkpoint a running microVM, keep going, and rewind it back to that exact point whenever you need to.

Arm support — Unikraft on ARM hosts. Expect 10–40% better compute economics depending on workload and up to 60% lower energy draw, underneath the density you already get from us.

JS/TS SDK — A JavaScript/TypeScript SDK: one client for your whole account, every metro queried in parallel, operations chaining off resource references. Coming to all customers.

…and several others we are not listing, because we do not want to spoil all of the fun. 🙂

Get your hands on Release 12