Skip to main content
Version: Deploy 26.1

Digital.ai Deploy 26.1.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 upgrade process depends on your current and target Digital.ai Release versions.

For upgrade instructions, see:

Updated System Requirements​

Deploy 26.1 supports the following latest versions of Java, operating systems, and databases. Before upgrading, ensure your environment meets the following requirements:

  • JDK: Supports OpenJDK 21
    (Oracle JDK 17 and OpenJDK 17 are no longer supported)

  • Windows Server: 2025, 2022
    (2019 is no longer supported)

  • RHEL: 9.x, 10.x
    (8.x is no longer supported)

  • PostgreSQL: 17.5, 16.9
    (17.2 and 16.6 are no longer supported)

  • PostgreSQL (provided with Bitnami Helm Chart): 17.6

  • MySQL: 8.4 LTS
    (8.0 LTS is no longer supported)

  • SQL Server: 2022 (16.0)
    (2019 (15.0) is no longer supported)

For more information, see Installation Prerequisites.

Breaking Changes​

Breaking changes in Deploy 26.1 require your attention before upgrading:

RabbitMQ Topology Operator Removed​

The RabbitMQ Topology Operator has been removed and its functionality is now handled directly by the upgraded RabbitMQ Operator. If your installation relied on the Topology Operator, review your configuration before upgrading to ensure any topology-related resources (exchanges, queues, bindings) are migrated correctly.

Changed Installation Answer Keys​

The following installation answer keys have been renamed:

Old KeyNew Key
PostgresqlInstallPostgresqlType
RabbitmqInstallRabbitmqType

Update any saved answers files or automation scripts that reference the old keys before upgrading. Using the old keys will result in an unrecognized-key error during installation.

Experimental External Operator Upgrades​

Upgrading between versions of experimental external operators (Bitnami alternatives) such as PostgreSQL, RabbitMQ, or Ingress-NGINX Controller may not work seamlessly. Review the Plan Your Kubernetes Installation or Upgrade before upgrading.

End-of-life Notifications​

Here's what is being deprecated or going out of support.

Apache Derby Deprecation Notice​

Support for Apache Derby, which can be configured for both Live and Reporting databases in demo or test environments (it is not recommended for production use), is deprecated starting with Deploy 26.1 and will be removed in Deploy 26.3.

The Apache Derby Project was officially retired in October 2025 and no longer receives bug fixes or security updates. As a result, Apache Derby will not be packaged with or supported by Deploy 26.3 and later.

Recommended actions:

If your current Deploy setup uses Apache Derby, you must replace it with another database before upgrading to Deploy 26.3.

important

Automated migration from Derby to another database isn't supported you must manually export and reimport your data.

  • Test and demo environments: You may use H2 database as an alternative.
  • Production environments: Use a supported external database.

For more information, see Configure the Deploy SQL Repository and Separate Databases for Reporting and Repository in Deploy.

If you are using Apache Derby and have concerns or questions about migration, please contact the Customer Support team for guidance.

GitOps in Deploy​

Deploy introduces GitOps support for bidirectional exchange of infrastructure and environment CIs with a Git repository using YAML files. It enables Infrastructure-as-Code workflows by allowing you to export CIs from Deploy to Git for versioning and review, and to import CIs from Git into Deploy to create or update them. Import and export are performed through a control task.

Supported Git providers: GitHub, GitLab, Azure DevOps, and Bitbucket (HTTPS only).

Key features:

  • Establish secure connections to Git repositories using personal access token (PAT) authentication
  • Verify Git repository connectivity using Check Connection
  • Define and maintain infrastructure and environment CIs as YAML files (compatible with xl apply)
  • Store infrastructure and environment CIs as YAML in Git repository
  • Import infrastructure and environment CIs from Git into Deploy to create or update them
  • Export infrastructure and environment CIs from Deploy to YAML files in Git
  • Configure multiple Git directories per Git source, each pointing to a different branch or path

Supported CI types:

  • Infrastructure - Host and container definitions
  • Environments - Environment structures
note

Dictionaries, encrypted dictionaries for Environment values, and secret/key fields are not supported for GitOps import/export.

For more information, see:

Large Artifact Deployment​

Deploy now supports deploying artifacts 2 GB or larger, addressing the OutOfMemoryError errors seen in releases prior to 26.1. Large artifacts are transferred using a streaming approach instead of being fully loaded into memory, significantly reducing memory pressure during deployment.

All three artifact base types are supported: udm.FileArtifact, udm.ArchiveArtifact, and udm.FolderArtifact.

tip

Overall memory usage still depends on the Deploy heap size configuration, which should be sized appropriately for your environment and workload. For guidance, see Production Environment Installation.

By default, ZIP archives up to 2 GB are processed in memory. To adjust this threshold, see Customizing Large Artifact Deployments.

Permission Handling​

All deployments work as expected. However, for udm.FolderArtifact deployments, when a ZIP archive exceeds 2 GB or the source is a JAR archive, Deploy uses a streaming reader that cannot preserve POSIX permissions. In these cases, Deploy applies adaptive permissions - files matching a configurable executable-detection regex receive 755 (rwxr-xr-x), all others receive 644 (rw-r--r--). TAR-based artifacts preserve POSIX permissions regardless of size.

Key highlights:

  • Permissions for JAR archives - From 26.1, JAR-based udm.FolderArtifact deployments apply adaptive permissions. Previously, all files received 644.
  • Configurable in-memory threshold - A new inMemoryThreshold setting in deploy-artifact-resolver.yaml lets you lower the size at which Deploy switches from in-memory to streaming ZIP processing, reducing heap pressure during parallel deployments.
  • Executable file detection - You can customize which files are detected as executables using a configurable regex. For details, see Customizing Large Artifact Deployments.

Storage Support​

Large artifacts are supported with the following storage configurations:

  • Internal storage - Filesystem (default)
  • External storage - HTTP / HTTPS

Database-backed internal storage and Maven / JFrog Artifactory external storage are limited for artifacts larger than 2 GB. These limitations will be addressed in coming releases.

Limitations​

  • Artifacts larger than 2 GB aren't supported with database-backed internal artifact storage or Maven / JFrog Artifactory external storage.
  • The Deploy CLI doesn't support export, import, or deployment of artifacts larger than 2 GB. Use the Deploy UI or XL CLI instead.

For more information, see:

Kubernetes Installation Updates​

Deploy 26.1 introduces Kubernetes version updates, enhancements to the Bitnami alternative external operator installation, XL CLI fixes, and improvements to operator-managed resources.

This release now supports Kubernetes 1.20-1.34.

Bitnami Alternative (Experimental) External Operator Enhancements​

The Bitnami alternative (experimental) external operator installation has received several enhancements:

  • Private registry support: Operators can now be pulled from a private container registry.
  • Resource configuration: CPU and memory requests and limits are now configurable for operator-based installations.
  • OpenShift and SCC support: Operator-based installations now support OpenShift, including corrected Security Context Constraints (SCC) handling for all components.
  • Preserve PVC: Persistent Volume Claims can now be preserved for operator-based PostgreSQL.
  • Improved cleanup: Re-ordered cleanup prompts and removal of stale or redundant external operator resources.
  • Fixed resource ordering: Corrected apply order for external Ingress-NGINX resources.

For more information, see Plan Your Kubernetes Installation or Upgrade

Operator-Managed Resources​

  • MAX_RAM_PERCENTAGE configuration is now supported for Deploy, Central Configuration (CC), and Task Engine containers, enabling better control over JVM heap memory allocation.
  • Custom context root configuration now automatically prepends / if not present.

For more information, see:

Plugins and Integrations​

Atlassian Bamboo Plugin​

The Atlassian Bamboo plugin enables publishing DAR files to Deploy and triggering deployments directly from Bamboo build plans. The plugin supports configurable orchestrators, update deployment behavior, and failure handling options to streamline CI/CD workflows.

For more information, see Atlassian Bamboo Plugin.

AWS Plugin​

Deploy now supports deploying AWS Serverless Application Model (SAM) templates through the existing CloudFormation integration. SAM templates can be uploaded and deployed using the aws.cloudformation.Template CI, with automatic processing of the Transform directive.

Key Features:

  • Deploy SAM templates using the existing aws.cloudformation.Template CI
  • Automatic expansion of SAM templates into standard CloudFormation templates
  • Full support for serverless resources including Lambda functions, API Gateway, and DynamoDB tables
  • Compatible with existing CloudFormation operations

For more information, see AWS Plugin

Azure Plugin​

Deploy now supports managed identities for Azure Container Apps, Static Web Apps, and Web App Containers, enabling secure authentication to Azure services without storing credentials.

Key Features:

  • Configure system-assigned and user-assigned managed identities
  • Support for cross-resource-group identity references
  • Available for ContainerAppSpec, StaticWebAppSpec WebAppContainerSpec, and WebAppSpec

New Properties:

  • addSystemAssignedIdentity (Boolean): Enable system-assigned identity
  • userAssignedIdentities (List): Specify identity names or full resource IDs

For more information, see Azure Plugin - Managed Identity Support

Command Plugin​

Deploy now supports re-execution of Command plugin steps during update deployments, even when the command definition has not changed. Previously, identical commands were skipped, resulting in only the registration step being performed.

For more information, see Command Plugin

GitOps Plugin​

The GitOps Plugin is a bundled plugin in the Deploy task engine that enables Git-based automation for managing configuration items (CIs). It provides configuration types that connect Deploy to Git repositories, allowing you to import and export infrastructure and environment definitions as YAML files.

Features:

  • Establish secure connections to Git repositories using personal access token (PAT) authentication from your Git provider
  • Verify Git repository connectivity using Check Connection
  • Import infrastructure and environment CIs from YAML files in Git into Deploy
  • Export infrastructure and environment CIs from Deploy to YAML files in Git

Configuration types:

CI TypeDescription
git.GitSourceDefines the connection to a Git repository
git.GitDirectoryMaps a folder in Git by defining its branch, repository path, and optional export target directories. Must be created under a git.GitSource

For more information, see GitOps Plugin.

OSB Plugin​

The OSB plugin now includes configurable Preserve Existing deployment settings on the osb.Configuration CI. These properties control whether existing configurations on the target OSB domain are preserved or overwritten during deployment, and can be set directly in the deployment package or through the Deploy UI:

  • preserveExistingEnvValues - Preserve existing environment values
  • preserveExistingCredentials - Preserve existing credentials
  • preserveExistingAccessControlPolicies - Preserve existing access control policies
  • preserveExistingOperationalValues - Preserve existing operational values
  • preserveExistingSecurityAndPolicyConfig - Preserve existing security and policy configuration

For more information, see Oracle Service Bus Plugin.

WAS Plugin​

Deploy now supports Interactive Authentication for wsadmin execution in the WebSphere AS plugin. When enabled, the plugin no longer passes credentials as command-line arguments. Instead, credentials are securely provided through a daemon process after the wsadmin prompt appears, helping prevent exposure of usernames and passwords in process logs and command history.

Key Features:

  • Secure credential handling through a daemon process instead of command-line arguments
  • Prevents exposure of usernames and passwords in process logs and command history
  • Requires headless mode configuration on the target WebSphere server

For more information, see IBM WebSphere AS Plugin.

Bug Fixes-26.1.1​

  • D-42475 - Resolved an issue where rollback in WLS deployments did not complete all steps, which could cause subsequent deployments to fail.
  • D-42631 - Fixed EKS connections that use AssumeRole and ExternalID so that the assumed credentials are applied correctly for cluster access.

Bug Fixes-26.1.0​

  • D-41080 - Fixed an issue where deployments to Aurora PostgreSQL failed when executing \c commands due to .pgpass not being used correctly by PostgreSql 11.11 and above.
  • D-41171 - Fixed incorrect namespace references during SCC installation on OpenShift. Resolved an issue where the Security Context Constraints (SCC) installation on OpenShift used incorrect resource names and context references when Deploy or Release was installed in a custom namespace. The configuration has been updated to correctly reference the target namespace, ensuring SCC setup completes successfully in non-default environments.
  • S-124914 - Fixed CVE-2025-11226, CVE-2025-41254, CVE-2025-48924, CVE-2025-55163 vulnerabilities.
  • D-41496 - Fixed plugin-management pod failure when using an external PostgreSQL database during temporary pod operations.
  • D-40993 - Fixed incorrect application path handling when packaging nested udm.application objects. Deploy now consistently creates version 1.0 under the correct application even if an additional path is included in the manifest.
  • D-41486 - Fixed a segmentation fault issue in XL CLI on RHEL 9. XL CLI now runs reliably on RHEL 9 without crashing with a core dump error.
  • D-42188 - Fixed Helm chart deployment failure caused by template validation not considering cluster state. The plugin now uses server-side dry-run validation, ensuring Helm templates are validated against the actual cluster configuration.
  • D-41946 - Fixed incorrect handling of regex values in string resources for WAS plugin deployments. Regex values are now preserved correctly without unintended escaping, ensuring accurate configuration in WAS.
  • D-42010 - Fixed deployment failure in the Kubernetes plugin caused by missing isAKS attribute handling during update deployments. The plugin now correctly supports AKS-related logic without causing runtime errors during deployment execution.
  • S-127409 - Fixed an issue in the Helm plugin where chart repository passwords with special characters caused failures on UNIX systems. Password handling is now updated to ensure compatibility across environments and sensitive values are properly masked in logs.
  • D-42267 - xl generate now correctly creates the artifacts/ folder, preserving ZIP directory structure during extraction.