Skip to main content
Published: November 2026 API: 21.2.6 (upgrade from 20.0.20) | Classic GUI: 21.1.5 | New console: 1.2.16 Release 21.2.6 lets you add or remove network interfaces on running application instances without redeploying them, attach persistent data disks to Docker Compose runtimes, and introduces two-node high-availability clusters with a witness. It also makes large Terraform-driven deployments reliable at high parallelism, tightens API input validation, and resolves more than 40 issues. Review Changed Behavior and Known Issues before upgrading automation, scripts, or Terraform configurations. Several API calls that previously succeeded silently now return HTTP 400.

New Features

Change network interfaces on running application instances

New console only. You can now add, remove, or swap network interfaces on a deployed VM or container application instance without deleting and redeploying it. You can also move an interface to a different virtual network and update its access control rules in place. Adding, removing, or swapping an interface triggers one automatic restart of the application; the instance’s volumes are preserved. Requires the upcoming EVE-OS 18.x LTS on the node. See the following:

SMT-aware CPU placement

New console only. CPU placement now accounts for symmetric multithreading (SMT) sibling relationships when assigning vCPUs to physical cores. On nodes with hyperthreading enabled, you can choose whether a workload uses one thread per core or both SMT threads of each reserved core, so that performance-critical vCPUs are not placed on logical threads that share a physical core with other workloads. This removes cache and execution-unit contention between pinned vCPUs and gives more predictable latency and throughput for latency-sensitive workloads such as SD-WAN routing, IPsec encryption, and high-frequency data processing. CPU placement applies to VM and container applications on EVE-KVM nodes that report a CPU topology. See CPU Placement for Application Instances.

Persistent data disks for Docker Compose runtimes

Classic GUI and new console. A Docker Compose runtime edge app can now declare extra data disks after its boot image. A data disk is either a blank persistent disk owned by the instance, or an existing volume instance attached by its volume label. A labeled volume survives deletion of the runtime instance and reattaches to a new instance, so you can move workloads from other runtimes without copying data. Requires EVE-OS 14.5.0 LTS, or a 16.0.x LTS release on nodes with ZFS persistent storage. See the following:

Two-node high-availability clusters with a witness

You can create a two-node HA cluster backed by an etcd witness on the seed node, or convert a single-node cluster to two-node HA. If the seed node fails permanently, a quorum reset promotes the surviving node and keeps the cluster running on a single node until you add a replacement. Two-node HA is managed through the API and ZCLI.

Enhancements

Unified clusters

New console only. Edge Node Clusters and ZEDEDA Edge Kubernetes Service clusters are now a single cluster type. Every cluster runs application instances (VMs, containers, and Docker Compose workloads) with Longhorn storage and KubeVirt on each node. When you create a cluster, or later on its detail page, you can enable Kubernetes access to add kubectl, GitOps, Helm, the Kubernetes dashboard, and a cluster shell. Enabling Kubernetes access on a running cluster is non-destructive: existing application instances and storage stay online. You can also import an external Kubernetes cluster for GitOps and Helm delivery without ZEDEDA edge nodes. The cluster list at Infrastructure > Fleet > Clusters shows every cluster type in one view. Each entry shows a Mode badge (Edge Node Cluster, K8s Cluster, or Imported K8s Cluster), and all cluster types are managed through the /api/v1/cluster endpoints. See Clusters.

EVE-OS update history

Each edge node now keeps a history of its EVE-OS image updates. See Update EVE-OS on Nodes.

Bulk refresh and purge by project or device list

Bulk application instance refresh and purge no longer require an edge app. You can target a whole project, or narrow the selection with a device list. Instances that are already up to date are reported as not required instead of failing the job.

Docker Compose runtime deactivation

A Docker Compose runtime can now be deactivated after all of its Compose application instances are stopped. Deleting the runtime still requires removing the Compose application instances first.

More application instances per edge node

Application instances whose edge app has VNC disabled no longer consume a VNC display slot. This removes the previous limit of 63 application instances per edge node.

API additions

  • The device and application instance status-config list endpoints support sorting by field.
  • The Users API stores new console preferences (cortexSettingsCustom).
  • Virtual networks on Edge Node Clusters are marked as cluster-wide in the edge node’s configuration.

User interface updates

  • New console only. The application instance remote console now uses Edge View.
  • Application and edge node port fields are validated in the console. A port must be less than 65535.
  • The classic GUI login page shows an announcement about the new console.

Terraform

The zedcloud_auth_profile resource now works with OAuth authorization profiles, including create and terraform import.

Changed Behavior

Review the following changes before upgrading automation, scripts, or Terraform configurations. Entries are ordered by likely impact.

Fixed Issues

Application instances at scale

  • Bulk create, update, and delete of VM application instances at high Terraform parallelism (40 or more) no longer time out with HTTP 504 or leave instances behind, and no longer stall unrelated API calls.

Application instances

  • Deployments to an edge node no longer fail permanently after repeated deploy and undeploy cycles because VNC display slots leaked. Spurious “No free VNC port” errors during create bursts are fixed.
  • A removed and re-added network interface no longer shows the previous interface’s IP address.
  • Editing or removing a default access control rule in the deploy wizard no longer re-adds the original rule, which caused overlapping port maps when deploying a second instance of the same edge app. Duplicate port map entries are removed.
  • Updating interface access control rules or the network binding through the API is now applied. Previously, the request returned HTTP 200 without changing anything.
  • Creating a snapshot now returns the snapshot’s ID and name.

Edge apps

  • Deleting an edge app while an instance or policy is being created no longer leaves references to the deleted app. Image deletion and app list operations are faster on large enterprises.

App profiles

  • An edge node that leaves a project and rejoins it now gets its profile applications redeployed.

Edge nodes

  • Editing an edge node no longer switches off debug mode.
  • Generating a single-use EVE-OS installer no longer fails intermittently with HTTP 500.

Edge Node Clusters

  • Replacing a node in an Edge Node Cluster no longer deletes or orphans application instances and volumes, and a replaced node can now be deleted.

Resource usage

  • Fewer online edge nodes are missing from the device resource usage report. See Known Issues for the remaining limitation.

Login

  • Users without TOTP can now enroll when Enforce TOTP is enabled, instead of being stuck in a loop.

Projects

  • Filtering the project list by type no longer returns HTTP 500, and the type filter now applies to project status endpoints. Getting a single project now returns the correct device count.

Filters

  • The originType filter on brands, models, images, datastores, and apps is now applied when you pass enum names such as ORIGIN_LOCAL.
  • Filtering edge nodes by a tag value that contains & now works.

PCR templates

  • Searching PCR templates with a space in the name pattern no longer returns HTTP 400, and the list returns a total count.

Metrics

  • The unsupported MEMORY_TOTAL time-series metric, which always failed, is removed.

ZEDEDA Edge Kubernetes Service

  • Deleted clusters no longer stay in a deleting state for hours, and stale cluster entries are cleaned up. User deletion on clusters is faster.
  • New clusters no longer show the state None, and ZEDEDA Edge Kubernetes Service errors return a meaningful message instead of a generic HTTP 500.
  • Clusters with many failing Git repositories no longer destabilize cluster management.

Security

  • Device authentication and remote attestation checks are hardened.
  • Kubernetes Git and Helm repository credentials are no longer returned in API responses or written to logs, and secret listing is limited to projects the user can access.
  • Operators and admins can no longer modify EVE-OS images through the general image update API.
  • Connections to Kubernetes management require TLS 1.2 or greater, and third-party dependencies with known CVEs are updated.

User interface

  • New console only. The console no longer freezes on the edge node detail screen.

Known Issues

  • Two-node HA status shows Unknown. A healthy two-node HA cluster that has not changed for 5 minutes is shown as Unknown. The cluster keeps working; only the reported status is wrong. A fix will follow in a point release.
  • Network interface changes on running instances require a newer EVE-OS. Until EVE-OS 18.x LTS is available, interface changes on running application instances are not applied by the edge node.
  • The resource usage report can still miss some online edge nodes. A small number of online nodes might not appear in the device resource usage report.
  • Application and edge node port limits are checked only in the console. The API still accepts port numbers greater than 65535.
  • Snapshot API edge cases. A snapshot can be created on an instance that does not allow snapshots. Deleting or activating a missing snapshot returns HTTP 500 instead of 404.
  • App profile deployments are limited to nine application instances per edge node. Larger profile deployments do not complete.
Last modified on November 3, 2026