Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Crowd load-balancing

Based on unofficial(?) information it would seem that while Crowd does not officially support clustering, there might be some setups where it can be made to work.

The set-up that we have in mind is:

  • Two MySQL servers with failover. The cluster has a virtual IP that always points to the active node.
  • Two Crowd servers behind a load balancer. The Crowd instances would be configured to use the database server's virtual IP for database connections.
  • Applications only perform authentication through the load balancer. For administration tasks we can directly connect to just one of the Crowd nodes.

So my questions are:

  • Can we expect Crowd to work reliably in this kind of setup?
  • Do we need to disable authorization caching in Crowd?
  • Are there other caching considerations?
  • Do we need separate licenses for the load-balanced Crowd instances?

3 answers

1 accepted

1 vote
Answer accepted

We do exactly this, except we also do administration tasks through the LB.


1. Yes, although multi-step wizards (adding an application) don't work correctly if passed back through different servers (via LB). We turn off LB for the minute or so it takes to add a new application. Modifying an applicaiton works through the LB.

2. No.

3. Yes, you need to make sure you are using a Database Cache (not Memory) for Authentication Token Storage.

4. No, or at least that was what was mentioned in the forums years ago when I asked.



I know this question was back in 2012, but I just wanted to give everyone else who is looking for the solution just like me. Here's how I solved it.

The way I solved it is to add the load balancer IP address(es) that it trying to connect. If you look at the crowd log, you'll see the ip from the load balancer to the application, see below. Once I added the IP it's coming from in the crowd application/confluence/remote addresses and then restart confluence. I was able to login.   

example log from Crowd: Client with address '' is forbidden from making requests to application 'confluence'

I'm using AWS Load Balancer and EC2. It's connecting to my Confluence via internal IP instead of the DNS name. You don't need to change the and I have it set to the DNS name. You just need to add the internal IP that load balancer is requesting. 

And when the load balancer IP changes your configuration fails.

Load Balancer shouldn't get new IPs randomly. It's set once you created one. If you worried, then add the entire VPC like 

Depends on your LB, NLB can have static IPs (but only public IP and one per AZ), ALB's and Classic can't. If an LB becomes unhealthy  etc you will be switched seamlessly to a healthy one with new IPs (it's the cloud and how AWS guarantee high levels of availability), hence why you should use your LB DNS.

Your suggestion of using VPC CIDR is a valid alternative.

Like Hao Doan likes this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events