Skip to main content
Version: Deploy 26.3

Digital.ai Deploy 26.3.x Release Notes

Deploy 26.3 expands GitOps with Deploy on Event, a Technical Preview that lets Git changes trigger deployments automatically, alongside broader Infrastructure-as-Code support. This release also removes the Java Security Manager and installer-managed ingress controllers, and adds plugin updates across AWS, Azure, CyberArk Conjur, Helm, Jenkins, and Kubernetes.

This release includes:

Announcements​

This section highlights changes in Deploy 26.3 that may require action. It covers breaking changes to review before upgrading, as well as features and components that are being deprecated and are no longer supported.

Breaking Changes​

Please review these breaking changes in Deploy 26.3 before upgrading.

Java Platform Changes​

Deploy 26.3 ships as a single distribution that supports both JDK 21 and JDK 25. JDK 21 remains the default, and no JDK-related configuration changes are required to continue using it after upgrading.

JDK 25 is available as an optional runtime. Switching to JDK 25 requires updating the wrapper configuration. JDK 25 does not support the Java Security Manager that earlier Deploy versions use to sandbox script execution. If you use scripts, switching to JDK 25 changes the security model for script execution and requires you to review your script security configuration and test affected functionality before deploying to production.

Action Required

Action Required If: You want to run Deploy on JDK 25.

No Action Required If: You want to run Deploy on JDK 21, the default.

For more information, see Java Platform Changes: JDK 25 Support.

End-of-Life Notifications​

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

  • Apache Derby: Apache Derby is no longer supported. Deploy 26.3 uses H2 as the embedded database for non-production environments. Migrate to a supported production database (PostgreSQL, Oracle, MySQL, or SQL Server). For migration steps, see Database Setup and Migration Guidance. The startDatabase and stopDatabase scripts in the bin folder now start and stop the embedded H2 database as a TCP server instead of Derby. Running H2 as a TCP server is required when you use H2 with external workers. For more information, see Running H2 as a TCP Server for Master-Worker Setups.

GitOps in Deploy​

In Deploy 26.3, GitOps expands in two areas. Deploy on Event, available as a Technical Preview, is a new capability that lets Git changes automatically trigger deployments. Existing Infrastructure-as-Code workflows also gain new import controls, support for additional CI types, improved secret handling, and more authentication options for the bidirectional exchange of CIs with a Git repository using YAML files.

New in 26.3:

  • Dedicated GitOps menu: A new GitOps view is available under a new Operations section in the left navigation pane (alongside Monitoring). It provides a filtered view of the Configuration tree that shows only GitOps CIs and their directories, with dedicated icons for the GitOps menu, Git Source, and Git Directory CIs. You can create, edit, delete, and run control tasks (Check Connection, Import from Git, Export to Git) directly from this view.
  • Kind selection for import: The kinds to import can be selected - Configuration, Infrastructure, Environment, and Application. Deploy generates import steps only for the selected kinds, validates the selection, and displays a consolidated summary of all created and updated CIs.
  • Application import and export with file artifacts: Export and import the Application kind, including deployment packages that contain file artifacts such as file.File, file.Folder, and URI-based artifacts, validated across file system, database, and external worker storage. The export operation must run before import.
  • Permissions support: Apply directory-level permissions during import using kind: Permissions included within another kind's YAML file.
  • Include Secrets in export: A new admin-only Include Secrets checkbox in the Export to Git dialog controls whether secret values are included in the export, aligning behavior with the xl CLI. The option is unchecked by default and is greyed out for non-admin users.
  • Secret placeholder handling: Exported YAML files never contain plain-text secrets. Secret properties are written as placeholders while the actual values are stored in the Deploy database. On import, Deploy resolves these placeholders from the stored values, so the created or updated CIs have their secrets applied and Check Connection passes.
  • Fine-grained token support: Git Source CIs now support both classic and fine-grained personal access tokens (PATs) with the appropriate repository permissions.
  • Check Connection from the Git Source CI: The Check Connection action is available directly in the Git Source CI editor toolbar, between Save and Cancel. The button stays disabled until a new CI is saved.

Deploy on Event​

Deploy on Event lets Git changes trigger deployments automatically. When a tracked deployment file changes, Deploy detects the change, creates the deployment plan, and executes it.

note

Deploy on Event is available in Deploy 26.3 as a Technical Preview.

How Deploy on Event works

Deploy polls Git for changes. No inbound webhook is required. Each polling configuration tracks one deployment file and one target environment, which Deploy reads from that file. When a new commit changes the tracked deployment file, Deploy triggers the deployment. Unrelated Git changes are ignored.

Polling frequency is configured with a cron expression, allowing deployment files to be polled independently at different intervals.

Deploy on Event reuses an existing git.GitSource. The deployment file, target environment, and required permissions must already be in place.

For more information, see:

Plugins and Integrations​

Deploy 26.3 includes updates to several plugins and integrations. This section describes the new capabilities and enhancements for those plugins.

AWS Plugin​

Added a Tags property to supported AWS CIs (EC2 instances, ECS clusters, EBS volumes, VPC security groups, and S3 buckets), plus support for creating VPC security groups and EBS volumes.

For more information, see AWS Plugin.

Azure Plugin​

Added guides for deploying three additional Azure resource types:

  • Azure App Service: Web Apps, container-based Web Apps, Static Web Apps, App Service Plans, deployment slots, diagnostic logging, and site extensions.
  • Azure Function Apps: ZIP deploy, code deploy, and container image deployments, Function App deployment slots, and Triggered and Continuous Web Jobs.
  • Azure Container Apps: containers, init containers, ingress, secrets, volumes, scaling, and service bindings.

For more information, see

CyberArk Conjur Plugin​

  • Added JWT authentication to the ConjurServer CI. JWT supports two ways to provide the token: client credentials (supply a Client ID, Client Secret, Token URL, and Scope so Deploy obtains a JWT from an OAuth 2.0 provider) or a JWT token file path (point to a file containing the JWT written by an external process). Deploy can now connect to CyberArk Conjur Cloud (SaaS) in addition to the CyberArk Dynamic Access Provider and the Conjur Open Source server.

  • Reworked the CyberArk Conjur documentation with a clearer explanation of the ConjurServer, ConjurPolicy, ConjurDictionary, and ConjurLookupValueProvider CIs, plus an end-to-end example for retrieving a service account at deploy time.

For more information, see Manage secrets using CyberArk Conjur.

Helm Plugin​

  • Added support for OCI-based Helm registries (oci://) alongside traditional HTTP/HTTPS repositories, along with private repository authentication, flexible kubeconfig options, and Stitch validation. Documentation now includes setup prerequisites, best practices, and troubleshooting.

  • Added a new Install/Upgrade Flags field to the helm.Chart configuration item (under the Advanced section) for passing additional Helm command-line flags that are appended to the helm upgrade --install command at deployment time.

For more information, see Helm Plugin.

Jenkins Plugin​

Deploy server authentication now supports Basic Username/Password (default) and Personal Access Token with inline or stored credentials. Stored credential validation is enforced: Basic requires Username with password, and PAT requires Secret text. Existing configurations continue to use Basic by default after upgrade.

For more information, see Create a deployment package using Jenkins.

Kubernetes Plugin​

  • Added EKS authentication using a named AWS CLI profile on the k8s.Master CI, and Assume Role overrides at the k8s.Namespace level so namespaces under the same cluster can assume different IAM roles.

  • Added readinessProbeRetry and readinessProbeInterval properties on the k8s.Resources and k8s.ResourcesFile CIs to control how long and how often Deploy polls the cluster for the readiness probe check after a deployment.

For more information, see Kubernetes Plugin.

Installation and Upgrades​

This section explains how to keep Deploy supported and up to date. It covers the maintenance support policy, upgrade instructions for JVM and Kubernetes deployments, and the system requirements your environment must meet before you upgrade.

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 Deploy versions.

For upgrade instructions, see:

Updated System Requirements​

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

  • JDK: Supports JDK 21 and JDK 25
    (JDK 21 is the default. JDK 25 requires wrapper configuration changes. See Configure the JDK Version for Deploy.)

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

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

  • PostgreSQL: 18.3 / 17.9
    (18.0 and 17.6 are no longer supported)

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

  • Oracle: 26ai LTS / 19c LTS

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

For more information, see Installation Prerequisites.

Administration​

This section describes administrative changes in Deploy 26.3 that affect how you configure and run Deploy.

JDK Platform Changes: JDK 25 Support​

Deploy 26.3 adds JDK 25 support. On JVM-based installations, a single distribution runs on both JDK 21 and JDK 25, and the JDK-specific runtime parameters are controlled through the wrapper configuration file rather than through separate binaries. On Kubernetes, run the Deploy server on JDK 25 by using the container image tag with the -jdk25 suffix. JDK 21 remains the default and requires no configuration changes. For the full procedure, see Configure the JDK Version for Deploy.

Java Security Manager removal​

To support JDK 25, Deploy 26.3 no longer uses the Java Security Manager. This affects Deploy installations that used the SecurityManager sandbox for Deployfile script execution to isolate host OS and system resources. In earlier Deploy versions, when it was enabled, the SecurityManager prevented server-side scripts run through the Deployfile functionality from reading host files or accessing system resources. Additionally, free security updates for some JDK 21 distributions end in September 2026.

note

In Deploy 26.3, the SecurityManager sandbox is removed on both JDK 21 and JDK 25. Deployfile scripts that previously relied on the sandbox are no longer restricted, regardless of which JDK you run.

When upgrading to Deploy 26.3 with JDK 25, the following deprecated parameters must be removed from conf/xld-wrapper.conf.common:

wrapper.java.additional.4=-Djava.security.manager=java.lang.SecurityManager
wrapper.java.additional.5=-Djava.security.policy=conf/xl-deploy.policy

The conf/xl-deploy.policy file is no longer read as of Deploy 26.3. Deploy 26.3 ignores this file when it runs on either JDK 21 or JDK 25. After upgrading, remove any existing conf/xl-deploy.policy file from the Deploy installation. Any permissions previously defined in this file are no longer enforced. The Java Security Manager-based sandboxing mechanism has been removed, and Deployfile scripts are no longer subject to restrictions defined in conf/xl-deploy.policy.

warning

Wrapper configuration files may not update automatically during an upgrade if you have previously customized them. Review conf/xld-wrapper.conf.common after upgrading and apply these changes manually to ensure JDK 25 compatibility.

Action is required if either of the following applies:

  • Deployfile scripts run with the SecurityManager sandbox enabled, and you relied on it to restrict what those scripts can do. After upgrading to Deploy 26.3, the sandbox is no longer enforced on either JDK 21 or JDK 25, so you must apply alternative controls.

No action is required if any of the following applies:

  • Deployfile scripts are not used in Deploy.
  • Deployfile scripts run without the SecurityManager sandbox enabled.

There is no drop-in replacement for the Java Security Manager. Migrating off the SecurityManager sandbox may require script changes, alternative execution or isolation approaches, and customer-specific governance such as approvals and operational controls. No single security model applies to all installations, and the appropriate approach varies by deployment model (VM, Kubernetes, SaaS).

For more information on the SecurityManager sandbox, see SecurityManager configuration.

Bug Fixes-26.3.0​

  • D-43027 - Fixed an issue where static images in the Deploy UI returned 404 errors in the browser. After webpack build changes, image paths resolved to /dist/images where the files were missing. The images are now correctly copied from ciExplorerDist/libs/images to the expected /dist/images location in the deployment package.
  • D-41370 - Fixed a resource leakage issue in parallel deployment operations involving large deployment packages (>1 GB). Under heavy concurrent deployments, leaked resources could exhaust native memory and cause OutOfMemory (OOM) conditions. The fix adds proper resource cleanup to prevent memory exhaustion and improve deployment stability.
  • D-43007 - Fixed an issue where file.folder deployments could become unresponsive when deploying applications with identical content to the same installation path. Deploy now handles these deployments correctly without unnecessary delays or timeouts.
  • D-43290 - Fixed an issue where staged deployments of file.Folder artifacts could fail during initial and update deployments. Deploy now correctly handles artifact staging and copy operations throughout the staging lifecycle.