Skip to main content
Version: Deploy 25.3

Digital.ai Deploy 25.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:

Updated System Requirements​

Deploy 25.3 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 25.3 require your attention before upgrading:

Bitnami Secure Images Initiative—Kubernetes Operator Impact​

Effective September 29, 2025, Bitnami will restrict its public container image catalog to a curated set of security-hardened images. This change impacts only Digital.ai Deploy installations using the Kubernetes Operator. VM and cloud-based installations are not affected.

  • Bitnami images (PostgreSQL, RabbitMQ, Nginx, init containers, Helm chart hooks) are optional and provided for convenience.
  • To check if your installation is impacted, use kubectl commands to list pods and init containers using Bitnami images.
  • Mitigation: Upgrade to the latest Maintenance Release (MR) before September 29, 2025, or patch your Custom Resource (CR) to use the Bitnami Legacy repository. Patch scripts and migration steps are available in the documentation.
  • After September 29, 2025, any pod restart using old Bitnami images will fail unless patched.
  • Troubleshooting and recovery steps are provided for image pull failures and operator upgrade issues.

For more information, see:

file.Folder Archive-Based Deployments Require Preinstalled Commands​

As part of performance improvements, Deploy no longer performs runtime checks to verify if tar or unzip are available on the target host. These commands must now be preinstalled before deployment. If they are missing, any archive-based copy strategy (Tar, ZipWindows, ZipUnix) will fail.

  • Linux: Make sure both tar and unzip commands are installed.
  • Windows: Ensure PowerShell 5.0 or later is available, with unzip support enabled.

For more information, see:

RabbitMQ 4.x and Quorum Queues​

From operator version 25.3 or later, RabbitMQ is upgraded to version 4.x, and quorum queues are now used by default instead of mirrored classic queues.

For more information, see Manual Upgrade RabbitMQ.

AWS SDK for Java v1.x Support Removed​

Support for AWS SDK for Java v1.x (including awsCredentials and awsRegions) in XL CLI Blueprints has been removed in Deploy 25.3 and later. Any functionality relying on AWS SDK for Java v1.x will no longer work. Please ensure you have migrated to AWS SDK for Java v2.x.

End-of-life Notifications​

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

Bitnami Helm Charts Being Deprecated​

Bitnami Helm charts are deprecated starting with Deploy 25.3 and will be completely removed from installation options in Deploy 26.1 and later versions. This affects Kubernetes Operator installations that rely on Bitnami-provided PostgreSQL, RabbitMQ, and other services. All installations that depend on the Bitnami Helm charts will remain available through the 25.3 version, but without image patch upgrades. It's recommended to plan migrating to external databases and message brokers or alternative deployment methods for production environments before upgrading to Deploy 26.1.

Personal Access Tokens (PAT)​

You can now use Personal Access Tokens (PAT) for secure, passwordless authentication with Digital.ai Deploy APIs. PAT provide a safer alternative to username–password authentication, especially for automated use cases. Users can manage their tokens in the new Access Tokens tab of their profile. PAT are also supported for SSO-authenticated users (for example, Office 365, Okta, or Azure AD).

Organizations can control whether SSO users are allowed to generate PAT through a system-level setting, keeping access aligned with the SSO provider’s active user and role state.

PAT PAT Table

Expiration Notification​

Users can now receive a one-time notification before their PAT expires, as configured by the Deploy administrator. The notification period (number of days) and the notification SMTP server used for email delivery can be set in Settings > Personal access token.

PAT Email Settings

For more information, see:

file.Folder and Copy Strategy Enhancements​

Copy Strategies Enhancements​

As part of performance improvements, the Tar and Zip copy strategies now unpack archives directly into the target folder using native commands (tar, unzip), skipping the temporary folder operations.

For file.Folder deployments, new configuration options are available to give finer control over how files are extracted from archives:

  • stripComponents – control how many leading path components are removed during extraction.
  • members – include or exclude specific paths and files.

For more information, see:

Copy Strategy Configuration Enhancements​

In Deploy 25.3, the artifact copy strategy can now be automatically detected based on the source archive type by enabling deploy.task.artifact-copy-strategy.autodetect: true in deploy-task.yaml.

A new global default copy strategy setting (Configuration/defaultCopyStrategy) allows teams to enforce consistent deployment behavior across environments when no strategy is defined in the Infrastructure CI and autodetect is disabled. New file.Folder CIs automatically use the global default, while existing CIs can be updated manually.

The overall precedence remains: Infrastructure CI settings take priority, followed by autodetect, then the global default, and finally the fallback OneByOne strategy. These enhancements give teams better control over deployment behavior while maintaining backward compatibility with existing setups.

For more information, see Copy Strategies.

API for Inherit from Parent Permission Setting​

We introduced API endpoints to manage the Inherit parent permission setting for configuration items (CIs). This applies to Directory CIs under Applications, Environments, Infrastructure, and Configuration items.

  • GET /permission/inherit-parent/{ID} - returns whether a Directory CI inherits permissions from its parent.

  • GET /permission/roles/{ID} – returns the list of role-based permissions for a CI and indicates if it inherits from its parent.

  • PUT /permission/roles/{ID} – enables or disables inheritance of permissions from the parent CI and optionally updates role permissions.

    Inheritance settings:

    • inheritParentPermission: true - the Directory CI inherits permissions from its parent.
    • inheritParentPermission: false - the Directory CI uses explicit permissions defined in rolePermissions. Be sure to review and provide the role permissions when disabling inheritance setting.

For more information, see Directory Permission Inheritance Management APIs.

Log Download Feature​

You can now download logs for individual deployment steps directly from the Deployment step preview window in the Report section, available on both Deployment and Control task pages. This works across all supported targets, including Localhost, SSH, and AWS Cloud, making it easier to access step-specific log content for troubleshooting.

For more information, see Using Deploy reports.

Unifying Task Types​

The task type previously shown as Update is now consistently returned as Upgrade in Reports > Deployments and Explorer > Monitoring > Deployment Tasks, including filters.

  • originalType – new property that standardizes task type values across the Deploy UI and API.
  • type – continues to return Update for backward compatibility.

Impacted API endpoints with Unifying Task Types are listed below:

  • POST /report/tasks – Returns archived deployment tasks, optionally filtered by parameters such as date range, task type, state, or user.
  • POST /report/download/tasks – Generates a downloadable CSV report of archived deployment tasks using the same filter options.

For more information, see Report Service.

Backstage YAML-Based Application Provisioning​

You can now provision Digital.ai Deploy applications in Backstage using either inline YAML or YAML files from GitHub. This feature allows you to define your Deploy application configuration as YAML and apply it directly to Digital.ai Deploy through Backstage, supporting both manual and GitOps-compatible workflows.

For more information, see Provisioning Deploy Applications in Backstage Using YAML.

Plugin Manager Improvements​

Digital.ai Deploy 25.3 introduces improved plugin handling across both the Plugin Manager UI and CLI.

Handling Official and Custom Plugins​

A dedicated plugin metadata file now ensures consistent classification of official and custom plugins during installation via the Plugin Manager UI.

The Plugin Manager CLI supports official and local arguments to control plugin installation paths. In offline environments, plugins are installed based on these flags even without access to plugin metadata. Deploy automatically removes duplicate plugin entries when an official plugin exists in the local folder, preventing upgrade conflicts.

Core plugins - such as base-plugin, command-plugin, database-plugin, and others - are now visible in the Installed section of the Plugin Manager page, where they can be upgraded or reinstalled directly.

For more information, see Plugin Manager CLI.

Added Support for JFrog Artifactory for Plugin Repository​

JFrog Artifactory can now be used as a proxy for plugins that are currently hosted on Nexus, allowing it to act as a mirror for your plugin repository in secure, air-tight environments.

For more information, see:

Known Issues and Limitations​

Large Archive Files​

From Deploy version 25.3, customers may encounter issues when deploying archive files larger than 2 GB. Deploy currently loads the entire archive into memory during processing, which limits the maximum file size. We are exploring ways to improve this in future releases.

XL CLI Compatibility with RHEL 9.x​

XL CLI has compatibility issues with Red Hat Enterprise Linux (RHEL) 9.x versions, which may result in segmentation faults when running XL CLI commands. Use RHEL 10.x or other supported operating systems for XL CLI operations.

Kubernetes Installation Updates​

Deploy 25.3 introduces enhanced installation validation and experimental support for operator-based external dependencies, improving installation accuracy and cloud-native integration.

Enhanced Installation Validation​

The xl kube install command now monitors the actual deployment status during installation. The process:

  • Waits for Deploy operator pods to start successfully.
  • Validates that the operator’s Helm chart has been released.

If the deployment fails, the installation fails accordingly. This ensures that installation success accurately reflects the operational state of the Deploy instance.

Experimental Operator-Based Dependencies​

This release adds experimental support for using industry-standard operators to manage external dependencies in non-production environments:

  • PostgreSQL: CloudNativePG Operator
  • RabbitMQ: RabbitMQ Cluster Operator
  • Ingress: Ingress-nginx Controller

This feature is currently limited to the digitalai namespace and does not support OpenShift installations. Support for non-root and root read-only containers, resource configuration, and installation with custom or private registries will be introduced in future releases.

warning

These features are experimental and intended for non-production environments. The Bitnami-based deployment method remains fully supported.

Updated Configuration Keys​

Deprecated KeyNew KeyValuesNotes
EnablePostgresqlPostgresqlInstalloperator, chart (deprecated), externalOperator is experimental
EnableRabbitmqRabbitmqInstalloperator, chart (deprecated), externalOperator is experimental

New Cleanup Keys​

  • PostgresqlOperatorClean
  • RabbitmqOperatorClean
  • IngressNginxControllerClean

Ingress Enhancements​

IngressTypeGeneric now supports:

  • Ingress NGINX controller (experimental)
  • NGINX Ingress Bitnami (deprecated)
  • HAProxy Helm chart (deprecated)
  • External ingress controllers
  • None (no ingress)

For more information, see:

Plugins and Integrations​

Azure Plugin​

API Versioning and Revisions

You can now manage API versions and revisions in Azure API Management directly through Digital.ai Deploy. This enhancement allows you to define API version sets, create multiple versions of an API, and manage non-breaking updates using revisions all within your deployment workflow. With this support, you can evolve APIs safely, maintain backward compatibility, and streamline versioned API deployments without manual steps in the Azure portal.

Managed Identity Support for Container Apps

You can now configure Managed Identities in the ContainerAppSpec for Azure Container Apps. This feature supports both system-assigned and user-assigned managed identities, enabling secure authentication with Azure resources without the need to store secrets or client credentials in your application.

For more information, see Azure Plugin.

Digital.ai Deploy GitHub Actions (GitHub Marketplace)​

The Digital.ai Deploy GitHub Actions integration has been enhanced with modular workflows and flexible deployment options. You can now use individual actions like create, publish and deploy independently or execute multiple steps with combined workflows. The integration includes pre-built workflow examples demonstrating various deployment scenarios including single-step workflows with direct values, user inputs, and environment files, as well as multi-step workflows.

Github actions

For more information, see Deploy Applications Using GitHub Actions and Digital.ai Deploy.

Google Compute Plugin​

You can now upload deployment artifacts including files, folders, and archives from your deployment package to Google Cloud Storage (GCS) buckets. This feature supports both full replacement uploads and folder syncing, similar to AWS S3 functionality. Deploy also supports complete lifecycle management of Google Cloud Storage buckets directly from Deploy. Create new buckets with custom configurations, update existing bucket properties, and delete empty buckets as part of your deployment process.

Proxy and SSL Verification Support

You can now configure proxy server settings for all Google Cloud Platform API connections. Additionally, SSL certificate verification can be enabled or disabled for HTTPS connections to Google Cloud services, allowing for self-signed certificates in development environments.

For more information, see Google Compute Plugin.

IIS Plugin​

The IIS plugin now supports copy strategy available in the parent container overthere.Host. The iis.Server container type CI which is a subtype of BasePowerShellContainer can now inherit the configured copy strategy from its parent overthere.Host. With this enhancement, iis.WebContent (a subtype of BasePowerShellDeployableFolderArtifact) CI can be deployed to iis.Server using the inherited copy strategy.

Previously, deployments to iis.Server always used the default OneByOne copy method. From version 25.3, the copy strategy defined in the parent host is now applied automatically to child IIS servers, enabling performance improvements when using the tar or zip copy strategies.

JBoss Plugin​

The JBoss plugin now includes enhanced support for JBoss Application Server 7+ (including WildFly) while maintaining backward compatibility with legacy versions (JBoss AS 4, 5, 6). These improvements bring modern CLI-based inspection, better server control, and reliable deployment validation.

For more information, see JBoss AS plugin.

Kubernetes Plugin​

The Kubernetes plugin has been enhanced with new authentication and security features for AWS EKS and Azure AKS connections.

External ID Support for EKS Connections

The Kubernetes plugin now supports External ID configuration for AWS EKS connections when using assume role functionality. This enhancement provides an additional security layer for cross-account AWS deployments.

Entra ID Authentication Support for AKS Connections

The Kubernetes plugin now supports Entra ID (formerly Azure AD) authentication for Azure Kubernetes Service (AKS) connections. This enhancement allows you to configure AKS clusters that are integrated with Microsoft Entra ID for authentication.

For more information, see Kubernetes Plugin.

Bug Fixes—25.3.0​

  • D-35832 – Fixed an issue where deploying a file.Folder artifact with read-only files caused a “Permission denied” error during placeholder processing.
  • D-38708 – Fixed an issue where Deploy created many temporary tzp* files in the /tmp directory at startup and failed to clean them all up on shutdown, potentially causing disk space issues.
  • D-39077 – Fixed an issue where changes to podman.cli.Container properties (like Restart Policy Name) didn't trigger the correct delta actions during redeployment, causing only "Register deployeds" to run instead of stop, update, and start steps.
  • D-39142 – Fixed an issue in the Helm plugin where helm.K8SRelease.upgrade and helm.K8SRelease.deploy actions could fail with YAML parsing errors. This occurred during Helm upgrade and install operations when certain Helm chart values were processed.