Release 11 “Metis”: Snapshots, Sandboxes, and a Shield

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 anywhere — 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, everything grouped into the four themes that define R11.

Snapshotting & state

The foundation of R11 is a set of capabilities for capturing and cloning live microVM state — full memory and volumes — with essentially no downtime. Together, branching, checkpointing and persistent filesystems make stateful workflows on the platform a first-class thing: fork a running database to develop against it safely, launch sub-agents from a warm parent, or roll a workload back to a known-good point in time.

Branching

Branching creates a clone of an existing instance — including its full memory and volume state — by referencing a source instance in the instance-create call. As with creating 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 a branch is taken, rather than being paused for the duration of a copy.

{
  "name": "my-branch",
  "branch_from": { "name": "my-instance" },
  ...
}

Branching is the foundation for stateful workflows on the platform — fast, low-downtime cloning of live workloads for testing, scaling and recovery. It spans a wide range of use cases, from launching sub-agents to branching a large production database so you can safely develop against it.

Checkpointing

Checkpointing captures the state of a microVM — running or otherwise, 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.

{
  "name": "my-checkpoint",
  "from": { "name": "my-instance" }
  ...
}

A checkpoint enters a starting state while it is created and then transitions to a checkpoint state. Omit the name and it inherits the instance name plus a random suffix. The API ships a complete set of management endpoints for listing per-instance history, per-checkpoint lineage, and checkpoint details, as well as deleting checkpoints and patching properties such as delete-lock, tags, and autokill.

Checkpoints support an autokill property that removes a checkpoint automatically if it has not been loaded within a given window. Deleting an instance that owns checkpoints does not remove those checkpoints. You load a checkpoint by creating a new instance from it — freely configuring services, additional volumes and ROMs, just as with branching and templates.

{
  "name": "my-new-instance",
  "checkpoint": { "name": "my-checkpoint" },
  ...
}

Fully rewindable VMs — rewinding a VM to an arbitrary checkpoint in place, without spawning a new one — are not part of this release. Today, checkpoints are loaded by creating a new instance from them.

Checkpointing gives you low-latency, point-in-time recovery and reproducible starting states for running workloads — invaluable for debugging, experimentation and rollback.

Custom filesystems & persistent volumes

Unikraft Cloud now supports defining custom filesystems with custom hooks for operations like format, mount, unmount and delete. This enables volumes that are shared across a cluster — and so, persistent volumes for use cases like ephemeral agents whose state lives in volumes and is available across a set of nodes. Think shared storage backed by S3 with a POSIX interface, à la JuiceFS.

This brings cluster-level, shared filesystem capabilities for agentic and other workloads — state that follows the work, not the node.

Networking & security

R11 lays real VPC-style networking under the platform — multiple interfaces and fully custom configuration — and then builds on it to deliver the feature we are most excited about: a transparent network shield that lets an untrusted workload reach the Internet without ever holding a secret or getting unfiltered access.

Multiple network interfaces & custom configuration

microVMs can now be created with multiple network interfaces and fully custom network configuration.

{
  "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 primary: the private_ip returned for the instance always comes from it, and the proxy forwards traffic there. Omit ip and tap_name and a TAP device is drawn from the platform pool — specify both or neither. Interface names are user-global rather than instance-local, so another instance can reference yours as its relay. Omit name and it is auto-generated as <instance_name>-ethX. autoconfig (default true) controls whether the guest kernel configures the interface or leaves it to the app/image. An empty "network_interfaces": [ {} ] is valid and allocates one pool interface. When gateway or nameserver are unspecified, the platform derives them from the relevant interface’s network.

This enables real VPC-style topologies — public/private separation, custom gateways and nameservers — and forms the foundation the network shield builds on. The controller detects whether the guest kernel supports the feature, so existing images and workloads are unaffected.

Network shield & relay

The network shield transparently inserts a “shield” between a microVM and the public Internet — it filters traffic, and it can inject credentials or secrets for agentic and other use cases. It relies on a relay that redirects all traffic to and from one interface toward another, letting you set up a gateway/proxy VM and configure its interface as the relay for another VM’s interface.

{
"name": "my-sandbox",
"network_interfaces": [
  { "relay": { "name": "my-gateway-iface", "relay_dns": true } }
],
...
}

Multiple VMs can share a single relay. Managed interfaces with custom TAP devices are supported, and you do not need to enable VM-to-VM communication (which you would not want in a sandbox anyway). DNS requests can be passed to the relay or answered by the platform’s default DNS server via relay_dns (default true), which simplifies setups without a DNS server in the relay VM. A guest acting as a relay should have net.ipv4.ip_forward=1 and rp_filter=0 set.

Shield and relay make a genuinely secure sandbox possible: traffic inspection and secret injection are centralized in a controlled gateway, keeping untrusted workloads away from both secrets and unfiltered network access. And because the shield is a separate microVM, each shield instance is fully isolated from every other — you get isolation for your workload and for the shield protecting it.

Extensibility

The 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 too. Unlike running an HTTP server as a regular service, plugin HTTP access is authenticated exactly like a normal API call, requires no service group, and talks directly to the instance. With scale-to-zero enabled, the instance is woken for the request and stays up for its duration — exactly like a normal request.

Each plugin is exposed directly over an authenticated URL; everything after the plugin name is forwarded as the URL to the plugin.

https://api.<REGION>.unikraft.cloud/v1/instances/<UUID>/plugins/<PLUGIN_NAME>/*

You declare plugins at instance-creation time.

{
  "name": "my-instance",
  "plugins": [
    { "name": "my-plugin", "image": "user/myplugin:latest",
      "config": <arbitrary JSON>
    }
  ]
}

A plugin is a standard ROM image with an executable named init in its root. It is automatically loaded and mounted at /uk/plugins/<plugin_name>, started when loaded, receives its config via STDIN, and receives an --api_fd X argument carrying the socket file descriptor it uses to accept connections. Plugins are fully supported by PATCH, are loaded on the scale-to-zero / suspend / restart cycle like ROMs, and are inherited when an instance is cloned via branching or checkpointing.

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 — and a general extension point for custom in-instance functionality for any use case. We will surface it through the dashboard soon.

Platform & operations

Rounding out R11: a completely rebuilt dashboard, automatic reclaiming of disk, richer health checks, a small but welcome CLI fix, and enterprise docs that finally live online.

A revamped dashboard

A powerful product deserves a beautiful interface — so we completely revamped the dashboard. You can now check real-time metrics for all your resources and inspect instance logs, start and stop instances directly from the UI, and manage your organization, including user management. Coming soon: SSH directly into an instance, create and delete instances, and inspect the lifetime of an instance as you checkpoint or fork it — among other things.

This means better usability today, and a stronger UI foundation so future dashboard features ship faster and more consistently.

Image pruning

The agent now automatically prunes unused images from disk. When an image is no longer referenced by any running or stopped instance, it is garbage-collected to reclaim space — and pulled again on demand if needed later. Note that images pushed directly to the local registry are now eligible for pruning — push anything you want to keep to the global registry instead.

Improved health checks

The /v1/healthz endpoint now supports additional checks, including admin-defined ones for workflows like marking a node not-ready during upgrades or draining. Queried with root access, it can also return version and license metadata for easy remote inspection.

--follow for start / restart

unikraft already followed logs for run; now start and restart do too — --follow is consistent across all three.

Online enterprise docs

Enterprise documentation has moved from a static, periodically-distributed document to a centralized online portal — always current, updated immediately, one source of truth.

A sneak preview of what’s next

Public release notes will now ship once a month. Here is a taste of what the next release has in store:

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

Get your hands on Release 11