DAI 25.4 Release Notes
The notes below provide descriptions of the new features and changes introduced with each release of Eggplant DAI. You are strongly encouraged to read about the relevant changes whenever you upgrade from an earlier version.
Potential compatibility issues are highlighted.
To the extent you are entitled to a copy of the source code for the open source software distributed with this product, a free copy will be provided. Please contact us with your request.
System Requirements
You can find supported operating systems and system recommendations on the Prerequisites page.
Before you upgrade, make sure that you stop all your DAI servers and services, and then take a backup of your database folders (data and minio) and configuration file (config.yml) before you start your installation. If there is a problem with your upgrade, you will need to restore to this point. If you have any questions or would like help testing your database before you upgrade, please contact your Technical Success Manager or our Customer Support.
- Eggplant DAI 25.4 is the latest major release.
- You must upgrade to Eggplant DAI 25.3 before you start your 25.4 upgrade.
- The upgrade may take 10-20 minutes to complete.
- Eggplant DAI 25.4 is only compatible with Eggplant Functional (EPF) 25.4.x When you upgrade to Eggplant DAI 25.4, you must also update your version of EPF.
For information about upgrading DAI container deployments, see Upgrading on the Deploying Eggplant DAI in Containers page.
The online documentation contains the latest information about DAI releases. If you are viewing this documentation online, you are seeing the latest update. If you are using the documentation embedded within DAI, please see the Release Notes on our Documentation website at: https://docs.eggplantsoftware.com/dai/dai-release-notes/ for the latest information.
The DAI Public API V3 will be released in a near future, and with it, we will be deprecating and removing Public API v1. Users are advised to make necessary preparations and move to a supported later version.
From DAI 26.1, TLS only will be supported – meaning your DAI Server must move to use HTTPS rather than HTTP only. This important change enhances application security and results from our Identity Access Management (IAM) solution only supporting HTTPS from the most recent version onwards. To upgrade to DAI 26.1 you will need TLS certificates in place – you should consult your organization’s Cyber/App Security function to arrange these certificates.
Release 25.4 (November 2025)
Version 25.4 of DAI includes the following enhancements and defect fixes:
Flexibility of Execution Engines and SUTs for Execution
Before DAI version 25.4, you could associate a system under test (SUT) with one or more DAI execution environments (EEs). The purpose of this functionality was to limit DAI's access to a SUT from only the associated EEs. For example, a SUT might be a physical device (such as a phone) that is connected to one particular EE with a USB cable, a system on a subnet that is only accessible from certain EEs, or a whole setup on a single system. So, you want to make that explicit to DAI. While this is not strictly necessary, users often associate every SUT with an EE, and it is not immediately obvious which EE will be used to execute a particular test configuration (test config).
Beginning with DAI 25.4, SUTs and EEs are unlinked, and you can specify in the test config which SUT and EE you want to use. As long as you verify that the EE and SUT can communicate with each other, you can use any SUT with any EE. This ensures that if someone is using the EE your test config was linked to with a different SUT, your execution will not fail when there is an available EE to use that also meets your criteria. Please scroll to steps 7 and 8 under the section Step 1: Configure the General Information for the Test Configuration on the Working with Test Configurations page for instructions.
You can choose to specify SUTs and EEs explicitly by name in your test config, or you can choose to select either by criteria tags. In either case, at runtime DAI will find an appropriate SUT and EE (through a connected agent) that meet the criteria and begin the test config run with them. (The run logs will tell you which resources were used). If a resource that meets the configured criteria tags is not available at runtime, the test config run will be put in a pending state until matching resources become available.
Where EEs and SUTs have a continuing requirement to remain linked (for example, if a SUT is physically connected only to one specific EE), you can configure this in the SUT setup > Advanced Settings. Selecting this SUT in a test config will automatically select the relevant EE for execution and prevent a different EE from being used.
To see an example of how you can configure which SUT and EE to use in your test configurations, click here.
SUTs can only be explicitly linked to a single EE in DAI version 25.4 and higher. Where an existing SUT has multiple linked EEs, DAI will simplify this to only the first in the list, and if you want to replicate the same behavior of using a specific set of EEs for that SUT, you should use EE tags in relevant test configs. You can also unlink a SUT completely (from any EEs) to allow the SUT to be used by any available EE.
Toggling off Use SUT is still possible if you handle SUT connections purely within your SenseTalk script.
If you are an Eggplant Cloud customer, you can also still choose to use an Eggplant-hosted SUT and/or EE.
Support for Multiple SUTs in Test Configurations
Alongside the flexibility to choose different combinations of DAI execution engines (EEs) and systems under test (SUTs), DAI 25.4 also now supports the configuration of multiple SUTs in a test configuration (test config). For example, if you have a test config that runs end-to-end tests across multiple systems, this enhancement ensures that at runtime all the SUTs added to the test config will be locked for the duration of the text config run. This enhancement ensures that your tests can run smoothly without interruption or losing access to a SUT hijacked by another execution. Eggplant Functional (EPF) will establish the connection to each SUT at the start of a test config run. If any of the SUTs are unavailable, EPF will exit gracefully so you can get immediate visibility that your required resources are not all available. Please scroll to step 7 under the section Step 1: Configure the General Information for the Test Configuration on the Working with Test Configurations page for instructions.
To see an example of how you can add multiple SUTs to a single test config click here.
If one of your SUTs is strictly linked to a specific EE (as described in the note above in Flexibility of Execution Engines and SUTs for Execution), then that EE must be used for the entire test config and all SUTs must be either linked to the same EE, or able to communicate with it and not be coupled to another EE.
The connection logic of when your tests move to another SUT will need to be managed in your SenseTalk script using a connect command, but you can be confident that DAI will keep these resources locked until the test config run terminates. To define multiple SUTs in a test config, you will need to explicitly name them in the configuration; using criteria tags will not work. This is because you will need to identify the SUT in your SenseTalk connect command by name.
EPF inherently appends a _1 to the end of the SUT name, so it is necessary to use the following: connect <sut_name>_1 to switch a connected SUT in your SenseTalk script.
Git Integration Moves to the DAI Run Agent by Default
In DAI 25.3, we enabled you to move away from the Git Integration in EPF and use a new implementation in the Run Agent, including flexibility of the Git client if desired. This was configurable but not the default approach.
In 25.4 the Run Agent Git integration is the default approach, which means the Run Agent performs the synchronization of the test suites in your Git repository, instead of EPF. So now it is easier for you to enjoy the stability and performance that the new implementation offers. For more information about how the Run Agent integrates with Git repositories, please see Synchronizing Suites in a Git Repo with the Run Agent.
You can still use the old approach by setting SYNC_SUITES: 0 in the env: section of the DAI configuration file, config.yml, for Windows installations, or setting syncSuites: 0 in the Helm chart for Kubernetes deployments.
Support for Multi-Monitor RDP SUT Connections in DAI
DAI 25.4 brings the ability to define and use multiple monitors for Remote Desktop Protocol (RDP) connections. You can define the number of monitors your system under test (SUT) has in the SUT setup and DAI will ensure that EPF knows and can execute tests that use all the monitors configured for the SUT. Please see Step by Step: Entering RDP Connection Details for instructions.
To see an example of how you can use RDP SUT connections with multiple monitors, click here.
The SUT settings define the resolution that the connection will use for all monitors in the SUT connection, regardless of the native or primary resolution of each monitor.
If you want to use this feature in DAI, you must ensure that your Eggplant Functional (EPF) instance is not configured to use the newer (beta) RDP connection type. The beta RDP connection type in EPF does not support multi-monitor SUT connections at this time. DAI cannot detect which version of the RDP connection type EPF is using. When you create a SUT and select Connection type > RDP on the Add new connection panel, you will see the Monitors option regardless of whether the configured RDP connection will actually be able to use it.
Addition of the DAI Monitoring Dashboard
DAI 25.4 now includes the DAI Monitor test case dashboard, which provides the same information as the Test case dashboard, but for tests that are run with a User Performance Monitor (UPM). For more information, please see Monitor Test Case Dashboard.
Using UPM requires a special license. See User Performance Monitoring (UPM) for more information.
Defect Fixes
DAI 25.4 contains the following defect fixes:
-
Fixes an issue where the test case tag filter was showing as UUID rather than name on test config result screen. (CRD-1898)
-
Fixes an issue where Exploratory tests are not excluded when filtered on a test case tag. (CRD-1875)
Security Fixes
DAI 25.4 remediates the following security vulnerabilities:
-
Upgrades Keycloak to remediate CVE-2025-49146 and CVE-2025-55163.
-
Upgrades starlette to remediate CVE-2025-54121.
-
Upgrades Keras to remediate CVE-2025-8747.
-
Upgrades Erlang to remediate CVE-2016-1000107.
-
Upgrades webpack-dev-server to remediate CVE-2025-30360.
3rd Party Product Updates
| Component | Previous Version | Upgraded To |
|---|---|---|
| Keycloak | 26.3.0 | 26.3.4 |
| Python Libraries | - | All upgraded to the latest versions |
| Nginx | 1.28.0 | 1.29.1 |
| RabbitMQ | 4.1.1 | 4.1.4 |
| PostgreSQL | 17.4.1 | 17.6.1 |
| MinIO | 2025-05-24T17-08-30Z | 2025-09-07T16-13-09Z |
| Erlang/OTP | 26.2.5.11 | 26.2.1.15 |