diff --git a/pages/releases/index.mdx b/pages/releases/index.mdx
new file mode 100644
index 0000000..071ebe6
--- /dev/null
+++ b/pages/releases/index.mdx
@@ -0,0 +1,21 @@
+---
+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 notes for versions prior to Release 10 were distributed to customers directly. Public release notes begin with Release 10.
+
+| 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. |
+| 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 | | — |
diff --git a/pages/releases/r10-themisto.mdx b/pages/releases/r10-themisto.mdx
new file mode 100644
index 0000000..80c82d4
--- /dev/null
+++ b/pages/releases/r10-themisto.mdx
@@ -0,0 +1,284 @@
+---
+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.
+
+---
+
+## Tooling
+
+### CLI
+
+#### New `unikraft api` subcommand
+
+`unikraft api <endpoint>` 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
+```
+
+### 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
+```
+
+### 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/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 `<instance_name>-ethX`, falling back to `eth-<random suffix>`.
+`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.<REGION>.unikraft.cloud/v1/instances/<UUID>/plugins/<PLUGIN_NAME>/*`.
+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/<plugin_name>`, 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..b478e11 100644
--- a/zudoku.config.tsx
+++ b/zudoku.config.tsx
@@ -573,6 +573,16 @@ const config: ZudokuConfig = {
       icon: "book-a",
       to: "https://unikraft.com/glossary",
     },
+    {
+      type: "category",
+      label: "Releases",
+      icon: "tag",
+      items: [
+        "/releases/index",
+        "/releases/r11-metis",
+        "/releases/r10-themisto",
+      ],
+    },
   ],
   search: {
     type: "pagefind",
@@ -582,6 +592,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: [
     {