Mendix on Kubernetes 2.25.0 release notes (planned for release on Monday, January 19)

content/en/docs/deployment/private-cloud/private-cloud-cluster/private-cloud-storage-plans.md

@@ -145,6 +145,27 @@ If you delete an environment, make sure that it is completely deleted by running
 
 If the commands return a *not found* response, your environment database and blob file storage have been fully removed. If either the database or the blob file storage were not deleted, you must find and troubleshoot the reason, and then do a [manual cleanup](/developerportal/deploy/private-cloud-deploy/#delete-storage) if necessary. Until the cleanup is done, you should not create a new environment that uses the same name as the environment that is still being deleted.
 
+#### S3 bucket region might need to be set manually
+
+In Studio Pro version 11.6, the AWS S3 library was updated from version 1 to version 2.
+This new AWS library version can no longer automatically detect an S3 bucket's region from its endpoint address, and needs the bucket endpoint to be specified manually.
+The AWS S3 library is also updated in the latest LTS versions of Studio Pro.
+
+Mendix Operator 2.25 (or later versions) will automatically recognise an S3 bucket's region from its endpoint address:
+if the bucket endpoint has a `<subdomains>.<region>.amazonaws.com` format (or `<subdomains>.<region>.amazonaws.com.<suffix>` format for AWS China regions),
+the Operator use `<region>` as the S3 region name.
+
+If the S3 bucket endpoint doesn't match this format, the Mendix Operator will use a default `us-east-1` region, as this works with most S3-compatible buckets like [Minio](#blob-minio) and [Google Cloud Storage](#blob-gcp-storage-bucket).
+
+In some scenarios (legacy or custom S3 endpoints), this autodetection might not work correctly.
+In this case, you can manually specify the S3 bucket region by setting the [com.mendix.storage.s3.Region](/refguide/custom-settings/#commendixstorages3Region) Custom Runtime Setting.
+A manually specified `com.mendix.storage.s3.Region` will override the autodetected bucket region.
+
+Mendix Operator versions 2.24.2 (and older) doesn't autodetect S3 bucket regions. To use Mendix 11.6 (or the latest LTS versions), manually set the `com.mendix.storage.s3.Region` custom Runtime setting.
+Upgrading to Mendix Operator 2.25.0 (or newer) might be a better option.
+
+This issue doesn't affect [Azure Blob Storage](#blob-azure) or [ephemeral](#blob-ephemeral) data storage plans.
+
 ## Database Plans {#database}
 
 Every Mendix app needs a database to store persistable and non-persistable entities. A database plan tells the Mendix Operator how to provide a database to a new Mendix app environment.
@@ -913,6 +934,21 @@ If you would like to simply share a bucket between environments, or to manually
 Although we offer additional flexibility and provide other options, Mendix recommends using one of the options listed above.
 {{% /alert %}}
 
+{{% alert color="warning" %}}
+In Studio Pro version 11.6, the AWS S3 library was updated from version 1 to version 2.
+This new AWS library version can no longer automatically detect an S3 bucket's region from its endpoint address, and needs the bucket endpoint to be specified manually.
+
+Mendix Operator 2.25 (or later versions) will automatically recognise an S3 bucket's region from its endpoint address:
+if the bucket endpoint has a `<subdomains>.<region>.amazonaws.com` format (or `<subdomains>.<region>.amazonaws.com.<suffix>` format for AWS China regions),
+the Operator will use the `<region>` part.
+
+If the S3 bucket endpoint doesn't match this format, the Mendix Operator will use a default `us-east-1` region, as this works with most S3-compatible buckets like [Minio](#blob-minio) and [Google Cloud Storage](#blob-gcp-storage-bucket).
+
+In some scenarios (legacy or custom S3 endpoints), this autodetection might not work correctly.
+In this case, you can manually specify the S3 bucket region by setting the [com.mendix.storage.s3.Region](/refguide/custom-settings/#commendixstorages3Region) Custom Runtime Setting.
+A manually specified `com.mendix.storage.s3.Region` will override the autodetected bucket region.
+{{% /alert %}}.
+
 #### Create Account with Existing Policy {#s3-create-account-existing-policy}
 
 This automated, on-demand option allows to share an existing bucket between environments, and isolates environments from accessing each other's data.

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

@@ -10,16 +10,18 @@ Kubernetes allows you to update an app without downtime by [performing a rolling
 
 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.
 
-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):
+Starting from version 2.25.0, the Operator will automatically perform a Rolling update for any environment that meets the [prerequisites](#prerequisites-2.25.0):
 
-* The environment has two or more replicas.
-* The configuration update does not modify the app source code (MDA or container image).
+* The configuration update does not modify the app model (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.
+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 (source code) 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 %}}
 
-In addition Operator version 2.24.0 will automatically assign a PodDisruptionBudget to environments with 2 or more replicas. Any environment with two or more replicas will be configured with a PodDisruptionBudget that ensures that no more than 1 replicas are stopped by Kubernetes when scaling down a cluster node or preparing an OS upgrade.
+In addition Operator version 2.25.0 will automatically assign a PodDisruptionBudget to environments with 1 or more replicas:
+
+* Any environment with two or more replicas will be configured with a PodDisruptionBudget that ensures that no more than 1 replica is stopped by Kubernetes when scaling down a cluster node or preparing an OS upgrade.
+* Any environment with one replica will be configured with a PodDisruptionBudget that ensures that at least 1 replica is available when scaling down a cluster node or preparing an OS upgrade. This might cause some Kubernetes updates to be postponed, to prevent app downtime.
 
 {{% alert color="info" %}}
 Previous versions of the Operator did not manage PodDisruptionBudgets. Instead, any manually created PodDisruptionBudget would apply to a Mendix app.
@@ -29,12 +31,22 @@ If you have manually created PodDisruptionBudgets for an app, delete it and inst
 
 ## Prerequisites
 
-## Prerequisites for Operator version 2.24.0 and Higher{#prerequisites-2.24.0}
+## Prerequisites for Operator version 2.25.0 and Higher{#prerequisites-2.25.0}
+
+The Operator automatically performs a Rolling update for any environment that meets the following condition:
+
+* The configuration update does not modify the app model (source code, MDA or container image).
+
+{{% alert color="warning" %}}
+Mendix Operator versions 2.20.0 to 2.23.1 had an experimental feature that also performed database schema upgrades with a Rolling strategy. This feature was removed in Operator 2.24.0, as it does not work well with the latest Mendix Runtime security features.
+{{% /alert %}}
+
+## Prerequisites for Operator version 2.24{#prerequisites-2.24.0}
 
 The Operator automatically performs a Rolling update for any environment that meets the following conditions:
 
 * The environment has two or more replicas.
-* The configuration update does not modify the app source code (MDA or container image).
+* The configuration update does not modify the app model (source code, MDA or container image).
 
 {{% alert color="warning" %}}
 Mendix Operator versions 2.20.0 to 2.23.1 had an experimental feature that also performed database schema upgrades with a Rolling strategy. This feature was removed in Operator 2.24.0, as it does not work well with the latest Mendix Runtime security features.
@@ -45,7 +57,7 @@ Mendix Operator versions 2.20.0 to 2.23.1 had an experimental feature that also
 If any of the following conditions is true, the Operator always uses a **Recreate** strategy, performing a full stop of all of the app's replicas:
 
 * 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 one replica.
+* The app environment has no running replicas.
 
 Otherwise, the Operator performs a **Rolling** update automatically.
 
@@ -95,8 +107,12 @@ You can specify the following options:
 * **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:
-    * **maxSurge** – Specifies an absolute or percentage value for how many additional replicas can be added during the deployment process. The default **0** value means that no additional replicas are added during the rollout process, and instead existing replicas are stopped to avoid using additional cluster resources.
-    * **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped to be replaced with updated versions during the rollout process. The default **1** value means that at most one replicas would be stopped during the update process. Increasing this value speeds up the rollout process, but can cause performance issues.
+    * **maxSurge** – Specifies an absolute or percentage value for how many additional replicas can be added during the deployment process.
+      * For apps with 1 replica, the default value is **1**, to run an updated (replacement) replica in addition to the current replica, and prevent any downtime when possible.
+      * For apps with 2 or more replicas, the default value is **0**, so that no additional replicas are added during the rollout process, and instead existing replicas are stopped to avoid using additional cluster resources.
+    * **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped to be replaced with updated versions during the rollout process. Increasing this value speeds up the rollout process, but can cause performance issues.
+      * For apps with 1 replica, the default value is **0**, to ensure that at least one replica is running, and prevent downtime.
+      * For apps with 2 or more replicas, the default value is **1**, so that at most one replicas would be stopped during the update process.
 
 ## Configuring Pod Disruption Budget parameters in Standalone Environments {#pod-disruption-budget-in-standalone}
 
@@ -126,13 +142,63 @@ spec:
 
 You can specify the following options:
 
-* **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped if Kubernetes needs to evict them from a node. The default **1** value means that at most 1 replica can be stopped, and that Kubernetes needs to wait until a replacement replica becomes available. Increasing this value speeds up the rollout process, but can cause performance issues.
+* **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped if Kubernetes needs to evict them from a node.
+  * For apps with 2 or more replicas, the default value is **1** and means that at most 1 replica can be stopped, and that Kubernetes needs to wait until a replacement replica becomes available. Increasing this value speeds up the rollout process, but can cause performance issues.
 * **minAvailable** – Specifies an absolute or percentage value for how many replicas need to be remain available if Kubernetes needs to evict them from a node. Increasing this value slows down the rollout process, but ensures that less replicas can be disrupted.
+  * For apps with 1 replica, the default value is **1** to ensure that at least one replica is always available, and prevent downtime.
 
 {{% alert color="warning" %}}
 Kubernetes doesn't allow specifying values for both `maxUnavailable` and `minAvailable`, and specifying values for both of them will [result in an error](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget).
 {{% /alert %}}
 
+## Allowing downtime with Operator 2.25.0 and higher versions {#allow-downtime-2.25}
+
+By default, Mendix Operator 2.25.0 and higher versions will try to prevent downtime whenever possible, including apps with single replicas.
+
+In some situations (for example, Kubernetes cluster autoscaling or node upgrades), single-replica apps would be disrupted.
+The default Pod Disruption Budget prevents this from happening until a developer manually restarts an app (or scales it to two or more replicas).
+
+To prevent downtime when updating an app with one replica, the Operator needs to _temporarily_ run two or more replicas of an app.
+If the cluster doesn't have enough capacity to start an additional replica, this would block the app update (as this is the only way to process updates without downtime).
+
+If your app or cluster changes are blocked by this policy, you need to scale the app to 2 (or more) replicas, or manually allow the changes to be processed with downtime.
+
+The easiest option to do this is to manually stop the app, and then start it again.
+
+Alternatively, you can set custom Reduced Downtime Options in the Cloud Portal:
+
+* In the **Deployment Strategy Options**, set
+  * **Max Surge** to **0%**
+  * **Max Unavailable** to **100%**
+* In the **Pod disruption budget options**, set
+  * **Min Available** to **0%**
+  * **Max Unavailable** to **100%**
+
+{{< figure src="/attachments/deployment/private-cloud/allow-single-replica-downtime.png" alt="Allowing downtime in single-replica apps" class="no-border" >}}
+
+For Standalone environments, this can be specified in the MendixApp CR YAML:
+
+```yaml
+apiVersion: privatecloud.mendix.com/v1alpha1
+kind: MendixApp
+metadata:
+# ...
+# omitted lines for brevity
+# ...
+spec:
+  # ...
+  # omitted lines for brevity
+  # ...
+  replicas: 1 # This is only necessary for apps with 1 replica
+  # Add or update this section:
+  deploymentStrategy:
+    rollingUpdate:
+      maxSurge: 0
+      maxUnavailable: 1
+  podDisruptionBudget:
+    maxUnavailable: 1
+```
+
 ## Limitations
 
 * 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.

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

@@ -12,6 +12,19 @@ For information on the current status of deployment to Mendix on Kubernetes and
 
 ## 2026
 
+### January 19, 2026
+
+#### Mendix Operator v2.25.0 {#2.25.0}
+
+* We have extended the Reduced Downtime deployment feature to support apps running 1 replica.
+   This feature is enabled by default, and works by running two replicas of the app during updates.
+   For more details, see the [Reduced Downtime Deployment](/developerportal/deploy/private-cloud-reduced-downtime/) document.
+* We have added autodetection for AWS S3 bucket regions, which is required by the AWS SDK update in updated LTS Studio Pro versions.
+   Version 2 of the AWS S3 library removed built-in autodetection of an S3 bucket's region, and this is now handled by the Mendix Operator.
+   In some situations, it might be necessary to manually specify the S3 bucket region by setting the [com.mendix.storage.s3.Region](/refguide/custom-settings/#commendixstorages3Region) Custom Runtime Setting.
+* We have updated Azure authentication code to improve compatibility with Azure Government and Azure in China.
+* We have extended the [S3 IRSA Mode](/developerportal/deploy/private-cloud-storage-plans/#s3-irsa-mode) provisioner options, allowing to specify a path prefix and permissions boundary for IAM roles. Documentation on using this feature is available upon request.
+
 ### January 8, 2026
 
 #### Portal Improvements