Skip to main content
Version: Deploy 24.3

Digital.ai Deploy 24.3.x Release Notes

Support Policy​

For each version of Deploy, we provide maintenance support for 15 months. For more information, see Digital.ai Support Policy.

Upgrade Instructions​

The Digital.ai Deploy upgrade process you use depends on the version from which you are upgrading, and the version to which you want to go.

For upgrade instructions, see:

Upgrade Deploy—on JVM

Upgrade Deploy—on Kubernetes

Digital.ai Deploy 24.3.0 includes the following new features.

In an effort to streamline user management across Digital.ai's Release and Deploy products, we are unifying the way users are counted and displayed in Deploy. This alignment brings consistency in user management features between the two products, creating a more cohesive user experience.

Important:

  • External users authenticated through external providers (such as OIDC or LDAP) are now included in the license count. This is a major change from previous versions, where only internal users were counted. Previously, there was a defect that prevented external users from being counted. This defect has been resolved in version 24.3. If the license limit is exceeded, new external users will be restricted and will be unable to log in.

  • The Digital.ai Deploy license allows a specific number of users. If the user count exceeds the allowed limit, those users will be disabled and unable to access Deploy. To resolve this, you will need to either purchase additional licenses or disable other users.

  • During the upgrade to version 24.3, Deploy will automatically enable all internal users and previously logged-in external users, regardless of the license count, to ensure continued access.

Licensed User Count​

Your license comes with a particular number of users that can use the Digital.ai Deploy. If you exceed the user count allowed by the application, the users will be disabled and they cannot access Digital.ai Deploy. You must either purchase additional licenses or disable other users to access Deploy.

What Happens When You’re Close to or Exceed the Maximum License User Count​

Digital.ai Deploy displays an on-hover message with a license indicator as you near the maximum number of licensed users. This message shows both the current users with login permissions and the total number of users permitted by the license. It does not disrupt the user flow or access, allowing users to continue using all features until the limit is reached.

For example, the following indicator appears next to "Users" when license seats are remaining.

blue

Refer to the View License Information table that covers all the license availability scenarios.

User Management Changes​

The User Management page now provides a more comprehensive view of user information, including external users and the license indicator.

Enhanced User Details​

The new User management page includes additional fields such as Email address, Name, Type, Last active, and Enabled allowing admin users to see detailed information about each user. For more information, see User Management.

alt

Username Update​

After upgrading to version 24.3, the handling of usernames has been updated:

External Users: Usernames will now be captured, stored, and displayed in lowercase. This change addresses inconsistencies between the stored and displayed usernames, particularly when users enter different cases during login.

Internal Users: Usernames will be captured, stored, and displayed exactly as they were created, preserving the case as entered.

Enable/Disable User​

After upgrading to version 24.3, User management page displays both internal and external users (previously only internal users were displayed). All users will have their Enabled toggle set to ON, regardless of the available license count. However, if the number of enabled users exceeds the licensed limit:

  • License information indicator will display that "License limit reached".
  • Any new internal users you create will have their "Enabled" toggle turned off by default. When you hover over the toggle, a note will explain that you need to either disable existing users or increase your license seats.
  • The system also prevents new external users from being created or logging in.
  • If you modify any existing users, their "Enabled" toggle will be disabled, preventing access until the license seats are increased, seats are freed up, or other users are disabled to meet the license limit.

alt

User Validation and Error Handling​

If the license limit is exceeded or if there are common errors and validation issues, any attempt by an external user to access Deploy will trigger an error message. For more information, see User validation and error handling.

System Information Updates​

The "Users" section in the System Information page will now display additional details, including the number of both internal and externals licensed users, licensed internal users, and licensed external users. This update provides a clearer overview of your user license usage within Deploy. For more information, see System information.

Create a user with YAML​

Users list object in YAML now includes new attributes such as name, email, and enable to ensure consistency with the Deploy UI. For more information, see YAML snippets reference in Deploy.

Deploy CLI Changes​

Added the ability to create internal users with a full name and email address using Deploy CLI. For more information, see Create new users.

OIDC Authentication​

Added support for configuring emailClaim, and fullNameClaim properties, which are used to create and update user profiles when logging into Deploy for the first time. For more information , see Configure Digital.ai Deploy for OIDC Authentication.

XL CLI Changes​

Here's what's new and changed with the XL CLI.

Support for HA Setup​

If you are using a High Availability (HA) setup with a LoadBalancer, ensure that you replace the local URL (e.g., http://localhost:4516) with your HA LoadBalancer URL in the config.yaml file. This will allow the XL CLI to interact with the Deploy application in an HA environment. For more information, see config.yaml

Enhanced XL CLI Error Messages​

When deploying applications using the XL CLI (xl apply), if issues such as missing placeholders, wrong placeholders, or wrong configuration in the environment, the CLI provided minimal error information. This led to pipeline failures and required manual checking of the Deploy GUI for more details. Now, the XL CLI has been enhanced to provide more detailed error messages directly in the CLI output. For more information, see Deploy XL CLI behavior.

Vault Lookup for Credentials​

The XL CLI now supports exporting configurations that include external property details. When exporting YAML for configurations that use lookup providers, such as credentials.SmbHostCredentials or Infrastructure.SSHHost, the generated YAML now includes the details of external properties. This enhancement ensures that sensitive values, managed through lookup providers (e.g., passwords stored in external vaults), are represented accurately in the exported YAML files.

For example,

The generated YAML now contains sections like external-properties that specify lookup provider details, as shown below:

apiVersion: xl-deploy/v1
kind: Infrastructure
spec:
  name: Infrastructure/SSHHost
  type: overthere.SshHost
  os: UNIX
  connectionType: SCP
  address: 123.13.60.118
  username: Administrator
  external-properties:
    password:
      kind: lookup
      key: key
      provider: Configuration/SimpleLookup

Handling of Missing CIs​

A new YAML specification property failOnMissingCiRefs for environment CI has been added to enhance the environment creation process. If the required CIs are missing and the failOnMissingCiRefs flag is set to true, the environment creation fails. For more information, see Work with the YAML format for Deploy

Lock Mechanism for Concurrent Deployments​

The udm.deployedApplication now includes a lock mechanism that prevents concurrent deployments of the same application version into a single environment when allowConcurrentDeployments is disabled. For more information, see Lock Plugin.

New Property for Environment to Handle Missing Placeholder Values in CI Properties​

Introducing a new property at the environment level to handle missing placeholder values in CI properties. The property, Fail When Ci Property Missing Placeholder Value, allows you to control the behavior when a required placeholder value is missing at the artifact level.

The following screenshot shows a deployment failure with the Fail When CI Property Missing Placeholder Value option selected.

alt

For more information, see Handle Missing Placeholders Values.

Configure DNS TTL (Time to Live)​

Deploy 24.3 brings you the security.properties configuration file, which you can use to override the default JVM settings.

Deploy uses the JVM's DNS cache settings by default. The default JVM setting is set not to expire cached addresses. This may cause network problems with some services such as the Digital.ai Platform.

To overcome such issues, the DNS cache expiry is set to 30 seconds by default (the networkaddress.cache.ttl=30 property has been added by default to the security.properties file).

You can increase or decrease the DNS TTL per your requirements in the security.properties file.

Docker 'latest' Images​

The implicit 'latest' version tag is no longer supported for Deploy docker images. To use Docker images, it is now required to specify the release version, for example 24.3

Correct

docker pull docker.io/xebialabs/xl-deploy:24.3

No longer Supported

docker pull docker.io/xebialabs/xl-deploy

CentOS 7 Docker Images​

Deploy Docker images based on CentOS 7 are no longer available for Deploy 24.1.3 and 24.3.0 and later.

Note: Images based on dai-ubuntu:22.04 (Ubuntu 22.04) is the default flavor of Docker image available from 24.1.3 and later. However, CentOS 7 Docker images are still available for Release 23.3.x.

Kubernetes Installation Operator Enhancements​

Here's what's new and changed with the Kubernetes Operator-based installer.

RedHat Certified OpenShift Operator​

We are happy to announce that our Kubernetes Operator for Deploy has been certified by RedHat for use in OpenShift installations.

The Digital.ai Deploy operator is available in the RedHat Catalog

For more information, see Installation with Openshift Certified Operator.

Kubernetes 1.30 Support​

Digital.ai Deploy supports installation on plain multi-node Kubernetes clusters, on-premise, for versions 1.20 to 1.30 (1.30 is supported from Deploy 24.1.10 and later).

Slim Image and Setting Up JDBC and MQ Drivers​

Most third-party driver jars are not shipped with the product and need to be configured separately.

There is a new way to configure third-party driver jars. This makes it easier to manage them in a controlled way, without interfering with the installation and plugin jars.

For more information, see Setting Up JDBC and MQ Drivers.

Note: Supported from Deploy 24.1.4 and later.

We are also offering new image: the slim type. This original image contains a few drivers, like the default PostgreSQL one and the embedded ones for trial installations. The slim image does not container any drivers at all. This has the advantage that security scans will not fail on unused drivers, at the expense of having to install a driver jar manually.

Air-gapped Installation of Application Images​

We have enhanced support for running Deploy in air-gapped Kubernetes environments. For more information, see Air-gapped Installation of Application Images.

Note: Supported from Deploy 24.1.2 and later.

Security—Configure Read-only Root File System​

  • Deploy operator-based installation now supports the readOnlyRootFilesystem setting in containerSecurityContext, enabled by default to improve security. By setting readOnlyRootFilesystem=true, the container root file system mounts as read-only, preventing any modifications at the root level. This setup is especially useful for users who need strict control over writable directories.

With readOnlyRootFilesystem active, unauthorized changes—such as rewriting executables or altering specific files—are blocked. Even with root access, users cannot modify files in designated read-only directories. Only certain folders, like cache, remain writable, helping maintain secure, controlled operations.

Support Non-admin User of Cluster​

A non-admin user in a Kubernetes cluster can now install Deploy without needing admin-level permissions on the cluster. Key changes include:

  • Namespace-Specific Resource Creation: Resources can only be created in specific namespaces, removing the need for wider cluster permissions.
  • Restrictions on Cluster Resources: The installation skips creating cluster-wide resources like IngressClass and Route, keeping everything contained within the specified areas.
  • No Security Context Constraints (SCC): SCC creation is not required, which helps prevent privilege escalation and improves security for users with limited permissions.
  • Support for Random UIDs: The installation works with containers that use random UIDs, providing more flexibility for different cluster environments.

Plugins and Integrations​

Here's an overview of what's new and changed with plugins.

Azure Plugin​

  • Added support for creating web applications for containers. For more information, see Integration with WebAppContainer.
  • Modified plugin functionalities to use Java Truststore for validating requests in SDK and REST calls.

For more information, see Azure Plugin.

Digital.ai Deploy GitHub Actions (GitHub Marketplace)​

You can now set up a GitHub Actions CI/CD pipeline to build, publish and deploy applications using Digital.ai Deploy. The new github-actions-deploy GitHub Action helps in creating, publishing, and deploying application packages from GitHub repositories. For more information, see Deploy Applications Using GitHub Actions and Digital.ai Deploy.

Helm Plugin​

  • Enhanced the error messages for Helm deployments to address issues where a generic error messages were displayed during failures. The deployment process will now capture and display the specific error message instead of the generic messages, making it easier to diagnose and resolve issues.

  • Helm chart types have a new field OrderedConfigurationFiles to apply value files in the added order.

For more information, see Helm Plugin.

JBossDM Plugin​

  • Fixed an issue where undeploying an EJB JAR triggered a CliScriptException error.

For more information, see JBoss Domain plugin.

Terraform Plugin​

  • Fixed an issue where non-ASCII characters in the Terraform module file caused a UnicodeEncodeError during deployment.

For more information, see Terraform plugin.

Weblogic Plugin​

  • Added support for specifying SSL parameters in WLST commands. For more information, see SSL Configuration Override.

  • Fixed an issue where rules defined on custom types extending from WebLogic artifact types were not applied.

For more information, see Oracle WebLogic plugin

Bug Fixes and Field Incidents—24.3.5​

note

No defects have been fixed in this version.

Bug Fixes and Field Incidents—24.3.4​

note

This version was skipped, and 24.3.5 was released in its place.

Bug Fixes and Field Incidents—24.3.3​

  • D-37005 - Fixed an issue where warnings appeared in the master pod logs during HAProxy Ingress-based HTTPS installation while configuring the HTTPS keystore or secure ingress keystore.

Bug Fixes and Field Incidents—24.3.2​

Bug Fixes and Field Incidents—24.3.0​

  • D-34995 - Fixed an issue with loading Spring Cloud Config during the upgrade to 24.1.2 by updating the AWS SDK version from 1.12.735 to 2.26.17.
  • D-34646 - Fixed the Deploy vulnerabilities from AquaScan.
  • D-34984 - Fixed an issue with the json patch dictionary that was causing deployment failure. *D-34217 - Fixed an issue where generating a Keystore (JKS) in an HTTPS setup, with or without ingress, showed errors in the logs.