This page documents limitations on the ForgeRock Identity Platform when deployed on a Kubernetes cluster in the cloud.

On All ForgeRock Identity Platform Components

Docker images are not available for use in production deployments.

Except for several images that implement user interface elements, Docker images for use in production deployments of the ForgeRock Identity Platform are not available. Unsupported, evaluation-only images are available in ForgeRock’s public Docker registry. These images can be used for evaluation purposes only.

Before deploying the ForgeRock Identity Platform in production, you must build Docker images. For more information about building images for the platform, see Base Docker Images.

Cross-region deployments are not supported.

While you can deploy the ForgeRock Identity Platform on multiple zones within the same region on a cloud provider, you can not deploy the ForgeRock Identity Platform on multiple regions. All the pods in a deployment must reside in the same region.


DS live data and logs should reside on fast disks.

DS data requires high performance, low latency disks. Use external volumes on solid-state drives (SSDs) for directory data when running in production. Do not use network file systems such as NFS.

Adding DS pods to a cluster should be done in advance of anticipated additional load.

When you increase the number of DS pods in a cluster, they’re automatically provisioned with the same directory data in existing pods. You must allow time for the data provisioning to complete and new pods to become available.


AM must be reconfigured and restarted if the number of DS pods changes.

In DS 7.1, you can elastically scale the number of DS pods in Kubernetes. However, the AM configuration does not automatically respond to changes in the number of DS pods.

Because of this, you must modify the AM configuration after you scale the number of idrepo or cts pods in a running AM deployment.

Session stickiness is recommended for all deployments.

ForgeRock recommends that you configure your load balancer to use sticky sessions to achieve better performance.

Session stickiness is required for some deployments.

Two AM features are stateful, and require you to configure your load balancer to use sticky sessions:

  • SAML v2.0 single logout.

  • Browser-based authentication using authentication chains, which is deprecated in AM 7.1. Note that AM authentication trees are not stateful, and do not have this limitation.

The SOAP binding is not supported for SAML v2.0 single logout.

When deploying SAML v2.0 single logout, use the HTTP-POST or HTTP-Redirect bindings. The SOAP binding is not supported when AM runs in a container.

The shared identity repository is not preconfigured for UMA deployments.

The shared identity repository deployed with the CDK and the CDM is not preconfigured to store UMA objects, such as resources, labels, audit messages, and pending requests.

In order to use UMA in the CDK or the CDM, you’ll need to customize your deployment. For more information, see the User-Managed Access (UMA) 2.0 Guide.


The IDM repository is deployed in a single master topology.

The IDM repository is deployed as a single DS master. Failover to a secondary DS replica is available. Multimaster replication is not currently supported for the IDM repository.


There are no limitations for this release.