Skip to main content
Version: Deploy 26.3

Digital.ai Deploy 26.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 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: 2022 (16.0) (2019 (15.0) is no longer supported)

For more information, see Installation Prerequisites.

JDK Version and SecurityManager Changes​

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.

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:

Kubernetes Installation Updates​

Ingress Controllers No Longer Installer-Managed​

From Deploy 26.3, Deploy no longer includes ingress controllers as packaged Helm subcharts or as installer-deployed components. The Bitnami nginx-ingress-controller and haproxy-ingress subcharts are removed from the Helm chart, and the ingress-nginx-controller community manifest is no longer installed or upgraded by the installer.

Ingress is still fully supported. It is no longer managed or deployed by the installer, so you must bring your own, already-installed ingress controller, or opt out and configure ingress later. New installations are not prompted to install an ingress controller. Select the external ingress option and provide the ingress class of your controller, or select none to configure ingress later.

None of the removed controllers are automatically migrated. If you currently use an installer-managed ingress controller, apply the manual custom resource changes before upgrading. See Migrate Off Installer-Managed Ingress Controllers.

Kubernetes Version Compatibility​

From Deploy 26.3, the Helm chart no longer sets an upper bound on the Kubernetes version it accepts. Installing or upgrading on a Kubernetes version newer than the one the chart was built against no longer fails a chart compatibility check. The supported Kubernetes version is 1.23 or later.

Default PostgreSQL Version for Operator Installations​

Operator-based installations now use PostgreSQL 18.3 through the CloudNativePG (CNPG) operator as the default database for new installations.

caution

On OpenShift, the CNPG controller-manager pod can fail to start with a Security Context Constraint error when its requested UID falls outside the namespace's allowed range. Grant the CNPG operator service account an appropriate SCC before installing. See Troubleshoot Install or Upgrade on Kubernetes.

Operator and CLI Enhancements​

  • xl kube apply command: Apply previously generated Kubernetes manifests directly to a cluster without an answers file or blueprints, using xl kube apply -f <generated-templates-directory> -n <namespace> --server-type <deploy|release|release-runner>. See XL Kube Command Reference.
  • External operator images in xl kube images list: The image list now includes the external operator images (CloudNativePG and RabbitMQ Cluster Operator) used by operator-based installations, which helps when mirroring images to a custom registry. See Set Up a Custom Image Registry.
  • Automatic in-place PostgreSQL major-version upgrade: When xl kube upgrade is run with PVC preservation and the new Cluster template bumps imageName to a higher PostgreSQL major version, CNPG automatically triggers an offline in-place upgrade using pg_upgrade --link against the existing PVC. See Automatic PostgreSQL Major Version Upgrade (CNPG).

Migration Guides​

Plugins and Integrations​

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.

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.