Apache CloudStack 4.23 is a regular feature release. It contains 9 new features, around 22 improvements and more than bug fixes since 4.22.1.0, from 169 merged pull requests and 223 resolved items in the 4.23.0 milestone. It advances the platform in four areas: making networking extensible and self-service, strengthening security and identity at the volume and platform level, broadening enterprise storage support for KVM, and maturing data protection for organisations moving away from VMware. It builds on 4.22 and continues to harden day-to-day operations for administrators.

Networking gains a DNS Framework with pluggable providers, network orchestration extensions that can drive external systems, firewall rules on VPC public IPs, and more efficient public IP usage through VPC conserve mode. Security and identity add KMS-backed volume encryption, a restructured API key pair model with per-key permissions and validity, per-domain OAuth providers, and wider vTPM coverage. On the storage side, a modernised CLVM stack and a new NetApp ONTAP plugin bring enterprise block storage to open-source KVM. Data protection gains a native backup provider that writes to secondary storage, and incremental backups for NAS-based backup and recovery. The sections below cover each feature.

Storage

Modernised CLVM Support for KVM Block Storage

Apache CloudStack 4.23 reworks CLVM-based primary storage for KVM, making it a more reliable and production-ready block storage option for environments using iSCSI, Fibre Channel, or similar shared storage. The updated implementation improves cluster-safe operations through proper locking, and introduces a new generation CLVM stack (CLVM_NG) designed to align with modern Linux LVM capabilities. Where CLVM places RAW images on LVM, CLVM_NG places QCOW2 on LVM.

The volume lifecycle is more consistent and predictable across create, attach, detach, and delete operations. CLVM_NG adds live migration, hypervisor-level volume encryption, and support for full volume snapshots.

Two scope limitations are worth noting for planning. Incremental snapshots were removed from the scope of this release, and VM (instance) snapshots on CLVM_NG are not yet supported, being targeted for a future release. Deployments that depend on instance snapshots should continue to use the existing CLVM stack.

Taken together, these changes reduce operational edge cases and improve stability across multi-host clusters, which matters most for workloads that rely on shared block storage during a move from legacy or VMware-based environments to open-source infrastructure.

NetApp ONTAP Storage Plugin

A new primary storage plugin integrates NetApp ONTAP directly, rather than presenting ONTAP capacity through a generic protocol and losing visibility of the array. CloudStack manages ONTAP-backed primary storage itself, and storage operations initiated in CloudStack are carried out through the array’s own interfaces.

The integration covers the full storage pool lifecycle (create, delete, enable, disable, and entering or cancelling maintenance mode) as well as volume operations on ONTAP-backed pools, so volumes are provisioned and managed as part of normal instance workflows. Because the plugin sits behind the standard CloudStack primary storage abstraction, ONTAP pools appear alongside other primary storage types and are consumed through the same APIs and UI screens operators already use.

For organisations standardised on NetApp, this removes an obstacle to running CloudStack on existing storage investments, particularly where a VMware migration is underway and ONTAP is already the storage platform of record.

Configurable Template Replica Counts on Secondary Storage

New configuration keys control how many secondary storage replicas are created for public and private templates. In zones with several secondary storage stores, templates were replicated according to fixed internal behaviour, with no way to express that a heavily used public template deserves broad replication while a rarely used private template does not.

Replica counts can now be set separately for public and private templates, so replication policy follows actual usage. Widely consumed public templates can be placed on more stores to spread deployment load and improve resilience, while private templates belonging to individual accounts can be kept to fewer copies to conserve capacity.

Operators therefore get a direct lever over the trade-off between secondary storage consumption, deployment performance, and redundancy, which previously could only be influenced indirectly. In large multi-zone or multi-store environments, where template data can account for a substantial share of secondary storage, both the capacity saved and the change in deployment behaviour are measurable.

Data Protection

KVM Backup on Secondary Storage (KBOSS)

KBOSS (KVM Backup on Secondary Storage) is a native backup provider that stores virtual machine backups directly on CloudStack secondary storage. Protecting KVM workloads has generally meant integrating a third-party backup and recovery product, with the licensing, infrastructure, and operational overhead that comes with it. For smaller environments, and for operators who wanted backup without adopting an external appliance, that was often the reason there was no backup strategy at all.

KBOSS uses the secondary storage a CloudStack zone already has. It supports both full and incremental backups, so repeated backups of the same instance do not require repeated full copies, and it also supports compression and integrity validation of backup data. It plugs into the existing backup and recovery abstraction in CloudStack, covering backup offerings, schedules, and restore workflows, so it is configured and consumed the same way as any other provider through the API and UI.

This release also introduces a configurable allowed-provider list, giving operators explicit control over which backup plugins, third-party ones included, may be enabled.

Native data protection is therefore available to any KVM deployment with nothing additional to procure or maintain. Service providers get a backup capability they can offer without a partner dependency, and backup data stays within infrastructure the operator already controls.

Incremental Backups for NAS Backup and Recovery

The NAS backup and recovery provider for KVM now supports incremental backups. Every NAS backup was previously a full copy of the instance’s disks, so backup storage consumption and backup windows grew with retention, which made frequent schedules impractical outside small environments.

The provider now maintains backup chains: an initial full backup followed by incremental backups capturing only the changes since the previous point in time. Less data is written to the NAS target and each job takes less time, so recovery point objectives can be tightened without a proportional increase in storage. Restores continue to run through the standard CloudStack backup and recovery workflows, with the provider resolving the chain internally.

NAS-based data protection is therefore viable at a scale where it previously was not, while still using ordinary NFS or CIFS storage that operators already have. Together with KBOSS, KVM deployments now have two native paths to data protection, chosen on whether backups should live on secondary storage or on a dedicated NAS target.

Networking

DNS Framework

Apache CloudStack 4.23 brings DNS management into the platform. Users can manage DNS zones and records directly from CloudStack while integrating with external providers, starting with PowerDNS. The framework uses a plugin-based approach, so additional DNS backends can be integrated later through the same interface.

DNS servers, zones, and records become first-class resources, exposed through both the API and the UI. Users can register DNS providers, create domains associated with accounts or projects, and create, list, and remove records. Associating a DNS zone with a network lets CloudStack create, update, and remove records automatically in response to VM lifecycle events and IP assignments, which removes the manual DNS steps that usually sit alongside instance provisioning.

For service providers, DNS management inside the same portal, scoped to the tenant’s own account, is a self-service capability that previously meant sending customers elsewhere.

Network Extensions

The XaaS Extensions Framework now covers network lifecycle orchestration. CloudStack can integrate with external networking systems and delegate work during lifecycle events such as network creation, preparation, and teardown, which takes networking beyond the built-in providers.

A network extension registers against a Physical Network, a broader scope than the cluster-level registration used previously, and operates across all network types: Isolated Networks, VPCs, L2, and Shared Networks. By hooking into lifecycle stages, extensions let CloudStack coordinate with external systems such as Linux-based networking or SDN controllers while remaining the orchestration layer.

This makes it possible to support custom networking implementations without modifying CloudStack core, and without carrying a fork. Networking now follows the same extensible model already available for compute and workloads.

VPC Conserve Mode

Conserve mode now applies to VPC environments, allowing more efficient use of public IP addresses across tiers and services. Previously a public IP was limited to a single VPC tier, and the Source NAT IP could not be reused for services such as load balancing or port forwarding. With conserve mode enabled on the VPC offering, and on the network offering used by the VPC tier, the same public IP including the Source NAT IP can be reused across multiple services and tiers.

This simplifies network design and reduces the number of public IPs needed to expose applications. It also lowers the entry barrier for adopting VPCs, particularly where IP address availability is limited or billed. In aligning VPC behaviour more closely with isolated networks, CloudStack offers a more consistent networking model across network types.

Firewall Support for Public IPs in VPC

Firewall rules can now be applied directly to public IP addresses within a VPC, closing a long-standing gap between VPCs and isolated networks. Traffic filtering in a VPC previously had to be expressed through network ACLs applied at the tier level, which made it awkward to control access to a specific public IP or to protect services exposed through port forwarding and load balancing. Ingress and egress rules can now be defined against a VPC public IP using the same model administrators and users already know from isolated networks.

The feature applies to public IPs associated with a VPC, including those used for port forwarding and load balancing, and is exposed through both the API and the UI. Rules are managed per IP address, so access to a given service can be restricted without reshaping the ACLs of the entire tier. This matters more now that conserve mode allows one public IP, Source NAT included, to serve several services and tiers: the firewall rule is the natural place to express access control for a shared address.

Security configuration is therefore consistent across network types, which reduces the amount of VPC-specific knowledge needed to secure an environment. Teams migrating from isolated networks to VPCs carry their existing firewall practice over unchanged, and service providers get a clearer per-IP boundary for exposing multi-tier applications.

Security and Identity

KMS Support for Encrypted Volumes

Volume encryption keys no longer have to live on the Management Server. Apache CloudStack 4.23 introduces Key Management Service (KMS) support for volume encryption, with integration to external key management systems including HSM-backed solutions, and a built-in database-backed option for simpler deployments. Operators can separate key custody from infrastructure control without changing existing provisioning workflows.

The implementation follows an envelope encryption model. Data Encryption Keys (DEKs) are generated per volume and wrapped using centrally managed KMS keys (KEKs). Only the wrapped keys are stored in CloudStack, and operations such as wrapping and unwrapping can be delegated to external systems. Key lifecycle management is part of the feature, covering versioning and rotation as well as migration of existing passphrase-encrypted volumes to KMS, so encryption keys can be updated over time without disrupting running workloads.

This addresses environments where strict control over encryption keys is required. It supports deployment models ranging from the built-in provider to external HSMs, and existing encryption mechanisms continue to work as before.

API Key Pair Restructure

API keys are now a first-class resource. Instead of a single key pair per user, users can hold several at the same time, each with its own set of permissions and its own validity interval. Distinct credentials can be issued for distinct purposes, such as automation pipelines, monitoring systems, and third-party tooling, and each one can be reasoned about independently.

Because each key pair carries its own permissions, a credential used by a monitoring integration can be limited to read operations while an orchestration pipeline receives only the API commands it actually calls. Key pairs can also be given a start and end date, so credentials expire automatically rather than living indefinitely until someone remembers to rotate them. Creating, listing, and removing key pairs is available through the API and, as of this release, through a dedicated management interface in the UI.

The effect on credential hygiene is direct. Revoking access for one integration no longer invalidates every other automation a user owns, and least-privilege access becomes practical to implement. For organisations with compliance requirements around credential rotation and scope, this brings the API authentication model in line with what is expected of a cloud platform.

Per-Domain OAuth Providers

OAuth provider configuration moves from global to per-domain. Configuration previously applied to the whole installation, which made single sign-on difficult to adopt in multi-tenant deployments: every domain shared the same identity provider and the same application registration, regardless of who owned the users in that domain.

Each domain can now carry its own OAuth provider configuration for Google and GitHub, so tenants authenticate against the identity provider they already use without affecting other domains on the same installation. This release also adds Keycloak as an OAuth provider, which extends single sign-on to environments running their own identity broker rather than a public provider.

For service providers this turns OAuth into a genuinely multi-tenant capability: each customer domain can be onboarded with its own identity configuration, and delegating authentication no longer costs tenant isolation. For enterprises, Keycloak means single sign-on can be built entirely on self-hosted identity infrastructure.

Keycloak as an OAuth Provider

Apache CloudStack 4.23 adds Keycloak as an OAuth2 and OIDC provider. Single sign-on previously meant Google or GitHub, which suited organisations already using those accounts but ruled out anyone required to keep authentication inside their own perimeter. Keycloak is the identity broker most commonly deployed for exactly that reason, and it can now be used to sign in to CloudStack directly.

Supporting Keycloak required making the provider endpoints configurable, because unlike a public provider there is no fixed URL to hard-code. The OAuth provider model gains two fields, an authorize URL and a token URL, carried through the database, the API, and the UI. Both can be set when registering a provider and changed afterwards, using the register, update, and list OAuth provider APIs, and both are editable in the UI. Registration validates that a Keycloak provider has both URLs before it is accepted. Once registered, Keycloak appears as a sign-in option on the login page.

For enterprises and public sector deployments where identity cannot leave the organisation, this closes the gap that kept single sign-on off the table. Together with per-domain OAuth configuration, each tenant domain can be pointed at its own Keycloak realm, so a service provider can offer single sign-on without every customer sharing one identity provider.

Support for vTPM on XenServer and XCP-ng 8.3/8.4

Virtual Trusted Platform Module (vTPM) support now extends to XenServer and XCP-ng 8.3 and 8.4, matching what is already available on KVM and VMware. Virtual machine instances on these hypervisors can use vTPM devices for secure key storage and platform integrity features inside the guest operating system.

The implementation uses the native capabilities of XenServer and XCP-ng. vTPM devices can be attached during virtual machine deployment, typically together with UEFI boot mode, allowing guest operating systems to use the TPM for disk encryption, secure boot, and attestation with no change to existing provisioning workflows in CloudStack.

With vTPM now available across all major hypervisors, security capability no longer depends on which hypervisor a workload lands on. That helps in heterogeneous environments and for administrators maintaining uniform configurations across hypervisor platforms.

Compute, Kubernetes and Operations

Multiple CD-ROM Devices per VM

A virtual machine can now have more than one CD-ROM device attached, addressing a long-standing limitation where only a single ISO could be mounted at a time. This matters most on KVM, where workflows such as Windows installation need simultaneous access to the OS installer and to additional driver media such as VirtIO drivers.

Users previously had to swap ISOs manually or prepare templates with external tools such as Proxmox or virt-manager, which added complexity and moved part of the workflow outside CloudStack. Multiple ISOs can now be attached either at deployment time or after the instance has been created, each in its own CD-ROM slot.

Template creation and day-to-day instance management are simpler as a result, with fewer steps in common scenarios and less dependency on external tooling. Initial support focuses on KVM, and the design allows for extension to other hypervisors depending on their capabilities and limits.

CKS: Affinity Group Selection at Cluster Creation

Affinity groups can now be selected when a CloudStack Kubernetes Service cluster is created. Placement of control plane and worker nodes was previously left entirely to the allocator, so a cluster intended to be highly available could end up with several of its nodes on the same host.

Affinity groups can now be specified as part of cluster creation, so anti-affinity rules can spread nodes across hosts, or affinity rules can be used where colocation is wanted. The selection is exposed through both the API and the UI as part of the normal cluster creation workflow and applies to the nodes CloudStack provisions on the user’s behalf.

Fault-tolerant clusters can therefore be built without post-provisioning intervention, and Kubernetes cluster placement now uses the same placement controls already available for individual instances.

Scheduled Autoscaling

Autoscaling groups can now schedule their minimum and maximum member counts. Groups have so far reacted to observed conditions such as load, which works for unpredictable demand but is inefficient when demand is known in advance: the group only begins to grow after the load has arrived, and the delay is visible to users.

Capacity boundaries can now change according to a defined timetable rather than only in response to metrics. An operator can raise the minimum size ahead of a known daily peak and lower it again overnight, while metric-based behaviour continues to operate within those boundaries. The underlying VM Schedule framework was refactored to be generic, making it reusable for scheduling beyond individual virtual machines.

Predictable load patterns such as business-hours traffic, batch windows, and seasonal campaigns can therefore be handled before the load arrives rather than after. For service providers, scaling behaviour also becomes explicit and reviewable, which makes autoscaling easier to offer as a managed capability.

Clone and Update Existing Offerings

Offerings can now be cloned and used as the basis for new ones, with broader support for updating offerings after creation. Compute, disk, network, and VPC offerings have historically been largely immutable, so introducing a small variation meant recreating the definition from scratch and re-entering every parameter. With cloning, an existing offering becomes a starting point: administrators duplicate it, adjust what needs to change, and save it as a new offering.

The feature covers the offering types administrators work with day to day and is available through both the API and the UI. This release also widens the set of fields that can be modified on an existing offering, which reduces the number of cases where an offering must be replaced, and existing resources migrated onto a new definition, because one attribute was set incorrectly or needs to change.

For operators managing large offering catalogues, this removes a good deal of repetitive and error-prone work. Variations on an established offering can be produced consistently, without a mistyped parameter quietly changing the behaviour of a service tier.

Availability and Next Steps

4.23 will matter most to teams running KVM at production scale, and particularly to those leaving VMware, where storage, backup, and key custody are usually what decide whether a migration goes ahead. The features above are configured through the standard APIs and UI, so adopting any one of them does not require rebuilding an existing deployment. Upgrade paths, database changes, and the full list of fixes are in the 4.23.0 release notes, and per-feature configuration detail is in the documentation.