App Connect

IBM App Connect: [“What’s New?”] Using custom volumes in IntegrationServers in containers

By Rob Convery posted Thu April 08, 2021 07:50 AM


Following the release of the IBM App Connect operator v1.3.0 we now support configuring volumes accessible by the integration servers.  This enables customers who use nodes such as file-nodes etc to easily move their existing pre-container environment into containers. 

Configuring a volume is performed via the CR of the IntegrationServer. There are two new fields to configure the volumes, these follow kubernetes standard formats to make it easy for those who have previous used volumes in deployments etc. 


Details of where to mount for one or more named volumes, into the runtime container. Use with spec.pod.volumes.

Follows the Volume Mount specification at For more information, see Volumes in the Kubernetes documentation.

The following volume mounts are blocked:
  • /home/aceuser/ excluding /home/aceuser/ace-server/log
  • /opt/ibm/ace-11/*


Details of one or more named volumes that can be provided to the pod, to use for persisting data. Each volume must be configured with the appropriate permissions to allow the integration server to read or write to it as required.

Follows the Volume specification at For more information, see Volumes in the Kubernetes documentation.

This setting must be used with spec.pod.containers.runtime.volumeMounts.

Example CR

Below is an example CR which would mount an empty volume into the /cache folder. This would enable you to deploy flows which read/write to the /cache folder.

kind: IntegrationServer
name: is-01-toolkit
version: 11.0.0
accept: false
license: L-APEH-BY5CY7
use: CloudPakForIntegrationProduction
barURL: ""
replicas: 1
designerFlowsOperationMode: disabled
endpointType: http
timeout: 120s
adminServerSecure: true pod: containers: runtime: volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}

Note it is the customers responsibility to:
* Make sure the folders/files have the correct permissions to be accessed by the IS. Depending on the nodes being used this will either need to allow "read" or "read/write" to all users because the IS runs using the "Restricted" SCC which means it will run as a random UID. 
* If running multiple replicas, make sure the storage class supports being read/ written to by multiple containers simultaneously. 

The format documentation on this capability can be found at