Skip to content


Product limitations

We haven't changed our Data Center applications' architecture to support Kubernetes. So, as is with all our Data Center products, the following limitations still exist:

  • We don't support horizontal or vertical autoscaling in our products. Read about Product scaling.
  • More pods doesn't mean that the application will be more performant.
  • We still have session affinity, so you will need to have a network setup that supports that.

Jira and horizontal scaling

At present there are issues relating to index replication with Jira when immediately scaling up by more than 1 pod at a time.

Indexing improvements

Please note that Jira is actively being worked on to address these issues in the coming releases.

Although these issues are Jira specific, they are exasperated on account of the significantly reduced startup times for Jira when running in a Kubernetes cluster. As such these issues can have an impact on horizontal scaling if you don't take the correct approach.


There are a number of known limitations relating to Bamboo Data Center, these are documented below.


With Bamboo DC 8.1 deployments to K8s using the Helm charts are now possible. This release does however contain an issue where partial unattended deployments to K8s do not work.

Unattended setup

Until this issue has been resolved, the recommended approach for deploying Bamboo server is using an unattended approach. That is, providing values to all those properties labeled as REQUIRED and UNATTENDED-SETUP within the values.yaml. This has the added benefit of eliminating any manual intervention (via the setup wizard) required for configuring Bamboo post deployment.

It should also be noted that the property, bamboo.unattendedSetup should be set to true (current default value) for this to work.

Cluster size

At present Bamboo Data Center utilizes an active-passive clustering model. This architecture is not ideal where K8s deployments are concerned.

1 pod clusters only

At present, Bamboo server cluster sizes comprising only 1 pod is the only supported topology for now.

Server and agent affinity

It is preferable that the Bamboo server and agents are be deployed to the same cluster due to security and performance reasons. If agents are deployed outside the Kubernetes cluster, you need to expose Bamboo server JMS port as LoadBalancer or NodeIP:

    enabled: true
    type: (LoadBalancer|NodeIP)

Security and performance considerations

If Bamboo server JMS port is exposed, it is highly recommended that you either allow access to it for Bamboo agents CIDR only (inbound security group rules if on AWS), and/or secure remote agent by configuring SSL for AMQ.

Deploying Bamboo agents to the same cluster with the server or at least to the same region/availability zone/datacenter is highly recommended to avoid performance and latency issues.

When configuring application links between Bamboo server and any Atlassian Cloud server product, the Bamboo server base URL needs to be used. See public issue for more detail.

Import and export of large datasets

At present there is an issue with Bamboo where the /server and /status endpoints become un-usable when performing an export or import of large datasets.

Data migration

For large Bamboo instances we recommend using native database and filesystem backup tools instead of the built in export / import functionality that Bamboo provides. See the migration guide for more details.

The Bamboo Helm chart does however provide a facility that can be used to import data exports produced through Bamboo at deployment time. This can be used by configuring the Bamboo server values.yaml appropriately i.e.

  type: import
  path: "/var/atlassian/application-data/shared-home/"

Using this approach will restore the full dataset as part of the Helm install process.


LoadBalancer service type

If a Kubernetes cluster has multiple cluster nodes and Crowd service.type is LoadBalancer, Crowd pods may receive client requests from different cluster node IPs. This will cause session invalidation in the client browser, which is a security feature of Crowd. You can resolve it by either:

  • Unticking "Require consistent client IP address" in Session configuration or
  • Configuring AWS LoadBalancer with session affinity by annotating a service. You can find more details in AWS LoadBalancer documentation.

Platform limitations

These configurations are explicitly not supported, and the Helm charts don’t work without modifications in these environments:

  • Istio infrastructure
    • Due to several reasons, Istio is imposing networking rules on every workload in the Kubernetes cluster that doesn't work with our deployments.
    • The current recommendation is to create an exemption for our workloads if Istio is enabled in the cluster by default.