Skip to main content
Version: Early Access

Digital.ai Deploy 26.1.x Release Notes

Early Access (EA) Releases​

Deploy Operator​

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​

Breaking Changes​

Breaking changes in Deploy 26.1 require your attention before upgrading:

RabbitMQ Topology Operator Removed​

The RabbitMQ Topology Operator has been removed. Operator versions have been upgraded accordingly. If your installation relied on the Topology Operator, review your configuration before upgrading.

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.

Experimental External Operator Upgrades​

Upgrading between versions of experimental external operators (Bitnami alternative) 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​

Plugins and Integrations​

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

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.

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.0​