Documented changes in the deployment strategy.

Removed options uses by previous Operator versions as they were
experimental and not compatible with Mendix Runtime's strict mode.

Author: zlogic

content/en/docs/deployment/private-cloud/private-cloud-operator.md

@@ -170,7 +170,6 @@ spec:
       azure.workload.identity/use: "true" # Example: enable Azure Workload Identity
   runtimeLicenseProduct: # Optional: Specify the type of product required for the Runtime License. This is applicable when PCLM is used for licensing. By default, the value is set to Standard, if left empty
   deploymentStrategy: # Optional: Specify a deployment strategy to reduce app downtime
-    type: PreferRolling
     switchoverThreshold: 50%
     rollingUpdate:
       maxSurge: 0
@@ -235,7 +234,7 @@ You must make the following changes:
     * `leaderless` - A mode where the nodes dynamically choose a leader. This feature is in preview mode. It requires Mendix Runtime 10.24 or newer, and Mendix Operator 2.23 or newer.
 * **customPodLabels** - Specify additional pod labels. Avoid using labels that start with the `privatecloud.mendix.com/` prefix.
     * **general** - Specify additional labels for all pods of the app.
-* **deploymentStrategy** - Specify parameters for the deployment strategy. For more information, see the reduced downtime deployment documentation.
+* **deploymentStrategy** - Specify parameters for the deployment strategy. For more information, see the [reduced downtime deployment](/developerportal/deploy/private-cloud-reduced-downtime/#deployment-strategy-in-standalone) documentation.
 * **runtimeReadOnlyRootFilesystem** - Specify if the Runtime container should mount the root filesystem in [read-only mode](/developerportal/deploy/private-cloud-cluster/#readonlyrootfs).
 
 #### Setting App Constants{#set-app-constants}

content/en/docs/deployment/private-cloud/reduced-downtime-deployment.md

@@ -6,25 +6,41 @@ weight: 35
 ---
 ## Introduction
 
-Kubernetes allows to update an app without downtime by [performing a rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/). Instead of stopping an app and then starting it with an updated version or configuration, Kubernetes can replace pods (replicas) one by one with an updated version. Existing pods handle requests until the newer version is fully started. Any changes in the [Data in the Domain Model](/refguide/domain-model/) need a database (schema) update. While the update process runs, you cannot modify any persistent entities.
+Kubernetes allows to update an app without downtime by [performing a rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/). Instead of stopping an app and then starting it with an updated configuration, Kubernetes can replace pods (replicas) one by one.
 
-The Mendix on Kubernetes Operator uses a [recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment) strategy by default. That is, the current version (configuration) of an app stops, and then the new version starts. Alternatively, the Mendix on Kubernetes Operator can use a **PreferRolling** strategy. That is, the Operator tries to perform a rolling update whenever possible. If the Operator detects that a database schema update is needed, it switches to a Recreate strategy to perform a full restart. If the new version of the app has model changes, deploying it requires a schema update. In this case, the Mendix on Kubernetes Operator automatically stops all replicas of the app, causing downtime.
+The Mendix on Kubernetes Operator uses a [recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment) strategy by default. That is, the current version (configuration) of an app stops, and then the new version starts.
 
-This feature works with Mendix on Kubernetes version 2.20 and later.
+Starting from version 2.24.0, the Operator will automatically perform a Rolling update for any environment that meets the [prerequisites](#prerequisites-2.24.0).
+
+1. The environment has 2 or more replicas.
+2. The configuration update does not modify the app source code (MDA or container image).
+
+{{% alert color="info" %}}
+Versions 2.20.0 to 2.23.1 of the Operator had an option to manually enable a **PreferRolling** strategy. That is, the Operator tried to perform a rolling update whenever possible. If the Operator detected that a database schema update was needed, it switched to a Recreate strategy to perform a full restart. If the new version of the app had model changes, deploying it required a schema update. In that case, the Mendix on Kubernetes Operator automatically stopped all replicas of the app, causing downtime.
+{{% /alert %}}
 
 ## Prerequisites
 
-You can enable the `PreferRolling` deployment strategy if your environment fulfills the following requirements:
+## Prerequisites for Operator version 2.24.0 and higher{#prerequisites-2.24.0}
+
+The Operator will automatically perform a Rolling update for any environment that meets the following conditions:
+
+* The environment has 2 or more replicas.
+* The configuration update does not modify the app source code (MDA or container image).
 
-* The app must have two or more replicas specified in the MendixApp CR or Developer Portal.
-* For Connected environments, the **Low Downtime Deployment Strategy** option must be enabled in the Cloud Portal.
-* For Standalone environments, **deploymentStrategy** must be set to **PreferRolling** in the MendixApp CR.
+{{% alert color="warning" %}}
+Mendix Operator versions 2.20.0 to 2.23.1 had a experimental feature that also performed database schema upgrades with a Rolling strategy.
+This feature was removed in Operator 2.24.0, as it doesn't work well with the latest Mendix Runtime security features.
+{{% /alert %}}
 
-If the app can be deployed without having to modify the database schema (model), it will now be deployed using a Rolling deployment strategy.
+## How the Operator chooses a deployment strategy
 
-## How a PreferRolling Strategy Works
+If any of the following conditions is true, the Operator will always use a **Recreate** strategy, performing a full stop of all of the app's replicas:
 
-When the Operator is configured to use a **PreferRolling** strategy, it will try to do an optimistic update and use a **Rolling** strategy. If the app needs to perform a database schema update, it signals to the Operator that it is waiting for approval to perform the update. The Operator then switches the app to use a **Recreate** strategy (stop all current replicas and start an updated version) and wait until all replicas of the app are running the same MDA version. Then, the Operator lets the app know that it is safe to update the database schema, and approve the process.
+* There are app pods that are running a different (older) version of the app image: there are changes in the app MDA or base OS image.
+* The app environment has 1 replica.
+
+Otherwise, the Operator will perform a **Rolling** update automatically.
 
 As a **Rolling** strategy can run multiple versions of the app at the same time, requests from the browser must be routed to a matching app version (that is, an app that has the same microflow or nanoflow parameters). The Operator uses Kubernetes service labels to perform an atomic switch, and instantly switch all clients to the updated version. This is done automatically once the number of updated replicas reaches a certain threshold. By default the threshold is 50% of all replicas. The value is specified in the [switchoverThreshold](#prefer-rolling-in-standalone) parameter.
 
@@ -36,23 +52,13 @@ Whether a change can be performed without downtime depends on the type of the ch
 * Changing environment variables, Runtime or Java options
 * Changing Runtime Metrics settings
 * Upgrading the Mendix Operator version
-* Rebuilding the same MDA version to get the latest CVE updates
-* Changes in microflows or Java actions that do not affect the model
-* Updating Java dependencies
-
-The following changes in the UI can be done without downtime, but as soon as the new version becomes available, all clients must log in again:
 
-* Page changes, including layout or CSS changes
-* Changes in nanoflows or microflow parameters, if the microflow is used on a page
-* Changes in JavaScript actions
+The following changes will cause a full restart and downtime:
 
-The following changes will be deployed with downtime, because the model must be updated:
+* Any changes that cause a modified MDA file
+* Rebuilding the same MDA version with a different base image version (e.g. switching to another Java version or installing the latest CVE patches)
 
-* Adding Marketplace modules that have persistent entities
-* Updating the object model in the app itself, or its Marketplace modules
-* Updating to a newer Mendix version
-
-## Using the PreferRolling Strategy in Standalone Environments {#prefer-rolling-in-standalone}
+## Configuring the Deployment Strategy parameters in Standalone Environments {#deployment-strategy-in-standalone}
 
 To reduce deployment downtime, add the `deploymentStrategy` section to your `MendixApp` CR, as in the following example:
 
@@ -69,7 +75,6 @@ spec:
   # ...
   # Add or update this section:
   deploymentStrategy:
-    type: PreferRolling
     switchoverThreshold: 50%
     rollingUpdate:
       maxSurge: 0
@@ -78,13 +83,8 @@ spec:
 
 For more information on the `MendixApp` CR, see [Editing CR](/developerportal/deploy/private-cloud-operator/#edit-cr).
 
-If the `deploymentStrategy` is not specified, the Operator will use the Recreate strategy and perform a complete restart on any changes, causing downtime. This follows how updates were processed by Mendix on Kubernetes versions before 2.19 and earlier.
-
 You can specify the following options:
 
-* **type** – Specifies a type:
-    * **Recreate** - The default setting
-    * **PreferRolling** - Try to deploy without downtime when possible
 * **switchoverThreshold** – Specifies a threshold of updated, ready replicas after which all clients should switch to the updated version. The threshold can be a percentage or an absolute value.
     For example, setting this to **50%** will switch all clients to the updated app version once 50% of all replicas are running the updated version. If not otherwise specified, 50% is used as the default value. This option is only used if the strategy **type** is set to **PreferRolling**.
 * **rollingUpdate** - Specifies parameters for rolling updates if the Operator is able to perform the update without a restart. These parameters are used as Kubernetes [rollingUpdate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) parameters:
@@ -112,8 +112,6 @@ spec:
 
 ## Limitations
 
-* This feature is only supported by Mendix Operator version 2.20 (and later).
-* If the new app version has UI changes, all clients are automatically logged out and will need to sign back into the app.
-* Deploying a new version of the app will cause downtime if there are changes in the domain model, or the Mendix version.
-* If an app is based on Mendix 9.12 or a later version, a Rolling update can run scheduled events on any replica. During an update, scheduled events might use a newer or older version of their associated microflows, which will be random. If there are major changes in a scheduled event microflow, consider temporarily disabling scheduled events during an update.
+* This feature is only supported by Mendix Operator version 2.24 (and later). Mendix Operator versions 2.20.0 to 2.23.1 used to have an experimental implementation of this feature; upgrading to 2.24.0 or later is highly recommended.
+* Deploying a new version of the app will cause downtime if there are any changes in the app MDA or the base OS image.
 * To ensure that scheduled events [are correctly synchronized at startup](/releasenotes/studio-pro/10.20/#improvements), it is recommended to use Mendix 10.20 or later.

content/en/docs/releasenotes/deployment/mendix-for-private-cloud.md

@@ -12,6 +12,14 @@ For information on the current status of deployment to Mendix on Kubernetes and
 
 ## 2025
 
+### October ???, 2025
+
+#### Mendix Operator v2.24.0 {#2.24.0}
+
+* We've simplified the approach of handling Rolling updates by the Operator. Any app with 2 or more replicas will be updated without downtime, as long as the app is running the same MDA and base OS image.
+* Starting from this version, all Operator upgrades will run without causing downtime (in environments that 2 or more replicas).
+* We've made a few adjustments to support changes in upcoming Studio Pro version numbers.
+
 ### September 25, 2025
 
 #### Portal Improvements