# Session State and Load Balancing Kibana 4

**URL:** <https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931>\
**Category:** Kibana\
**Created:** [April 20, 2016, 3:42pm UTC](https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931 "2016-04-20T15:42:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mhughes](https://avatars.discourse-cdn.com/v4/letter/m/85e7bf/32.png) [@mhughes](https://discuss.elastic.co/u/mhughes)\
**Post date:** [April 20, 2016, 3:42pm UTC](https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931/1 "2016-04-20T15:42:38Z")

</div>

Unlike Kibana 3, Kibana 4 stores user session state in the Kibana server. Is that accurate?

If this is true, how would one load balance Kibana? I could configure my load balancer to be sticky, but that would require me to terminate SSL at the LB, not Kibana, something I can't do.

I _think_ I can get around this by setting the following fields:

```auto
elasticsearch.preserveHost: true
server.host: ipOfKibanaHostNotLoadBalancer

```

If Kibana is storing session state in its server, I believe this will ensure that all requests go back to the server that served up this config file. So, as long as the user doesn't do a hard browser refresh, they should always hit the same server.

Can you tell me if this is accurate? What is stored in session state? What are the consequences of doing a hard-refresh in the browser and getting sent to a different Kibana server?

---

<div class="post-metadata">

**Author:** ![Joe\_Fleming](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joe_fleming/32/3561_2.png) [@Joe\_Fleming](https://discuss.elastic.co/u/Joe_Fleming)\
**Post date:** [April 20, 2016, 10:54pm UTC](https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931/2 "2016-04-20T22:54:04Z")

</div>

> [@mhughes](#):
>
> What is stored in session state?

I'm not sure what you mean by session state. The state of the app in Kibana 4 is actually stored in the URL. The user session is stored in the browser session, or in some cases, in localstorage. Long-term storage (saved visualizations and dashboard, for example) is all persisted in Elasticsearch, so if your Kibana instances are all talking to the same node, you shouldn't have any issue load balancing them.

---

<div class="post-metadata">

**Author:** ![mhughes](https://avatars.discourse-cdn.com/v4/letter/m/85e7bf/32.png) [@mhughes](https://discuss.elastic.co/u/mhughes)\
**Post date:** [April 21, 2016, 7:29pm UTC](https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931/3 "2016-04-21T19:29:33Z")

</div>

So if the server has no state, what does it do? It just proxies interaction with Elasticsearch for some performance benefit?

---

<div class="post-metadata">

**Author:** ![Joe\_Fleming](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joe_fleming/32/3561_2.png) [@Joe\_Fleming](https://discuss.elastic.co/u/Joe_Fleming)\
**Post date:** [April 21, 2016, 11:32pm UTC](https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931/4 "2016-04-21T23:32:39Z")

</div>

Right now, yes, it's really just a proxy layer and file server. That proxy makes it so users don't need to worry about CORS mostly, and it allows us to provide a very, very rudimentary layer of protection by whitelisting the types of requests a user can make (mostly blocking DELETEs through the proxy).

In the future we may offload more to the server, but I don't think that application and user state are likely to be included.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:55pm UTC](https://discuss.elastic.co/t/session-state-and-load-balancing-kibana-4/47931/5 "2017-07-06T13:55:24Z")

</div>