[[production]]
= Use {kib} in a production environment

++++
<titleabbrev>Production considerations</titleabbrev>
++++

How you deploy {kib} largely depends on your use case. If you are the only user,
you can run {kib} on your local machine and configure it to point to whatever
{es} instance you want to interact with. Conversely, if you have a large
number of heavy {kib} users, you might need to load balance across multiple
{kib} instances that are all connected to the same {es} instance.

While {kib} isn't terribly resource intensive, we still recommend running {kib}
separate from  your {es} data or master nodes. To distribute {kib}
traffic across the nodes in your {es} cluster,
you can configure {kib} to use a list of {es} hosts.

[WARNING]
====
{kib} does not support rolling upgrades, and deploying mixed versions of {kib} can result in data loss or upgrade failures. Please shut down all instances of {kib} before performing an upgrade, and ensure all running {kib} instances have matching versions.
====

[float]
[[load-balancing-kibana]]
=== Load balancing across multiple {kib} instances
To serve multiple {kib} installations behind a load balancer, you must change the configuration.
See {kibana-ref}/settings.html[Configuring {kib}] for details on each setting.

These settings must be unique across each {kib} instance:
[source,js]
--------
server.uuid // if not provided, this is autogenerated
server.name
path.data
pid.file
server.port
--------

When using a file appender, the target file must also be unique:
[source,yaml]
--------
logging:
  appenders:
    default:
      type: file
      fileName: /unique/path/per/instance
--------

Settings that must be the same:
[source,js]
--------
xpack.security.encryptionKey //decrypting session information
xpack.security.authc.* // authentication configuration
xpack.security.session.* // session configuration
xpack.reporting.encryptionKey //decrypting reports
xpack.encryptedSavedObjects.encryptionKey // decrypting saved objects
xpack.encryptedSavedObjects.keyRotation.decryptionOnlyKeys // saved objects encryption key rotation, if any
--------

[WARNING]
====
If the authentication configuration does not match, sessions from unrecognized providers in each {kib} instance will be deleted during that instance's regular session cleanup. Similarly, inconsistencies in session configuration can also lead to undesired session logouts. This also applies to any {kib} instances that are backed by the same {es} instance and share the same kibana.index, even if they are not behind the same load balancer.
====

Separate configuration files can be used from the command line by using the `-c` flag:
[source,js]
--------
bin/kibana -c config/instance1.yml
bin/kibana -c config/instance2.yml
--------

[float]
[[accessing-load-balanced-kibana]]
=== Accessing multiple load-balanced {kib} clusters

To access multiple load-balanced {kib} clusters from the same browser,
explicitly set `xpack.security.cookieName` to the same value in the {kib} configuration
of each {kib} instance.

Each {kib} cluster must have a different value of `xpack.security.cookieName`.

This avoids conflicts between cookies from the different {kib} instances.

This will achieve seamless high availability and keep the session
active in case of failure from the currently used instance.



[float]
[[high-availability]]
=== High availability across multiple {es} nodes
{kib} can be configured to connect to multiple {es} nodes in the same cluster.  In situations where a node becomes unavailable,
{kib} will transparently connect to an available node and continue operating.  Requests to available hosts will be routed in a round robin fashion.

In kibana.yml:
[source,js]
--------
elasticsearch.hosts:
  - http://elasticsearch1:9200
  - http://elasticsearch2:9200
--------

Related configurations include `elasticsearch.sniffInterval`, `elasticsearch.sniffOnStart`, and `elasticsearch.sniffOnConnectionFault`.
These can be used to automatically update the list of hosts as a cluster is resized.  Parameters can be found on the {kibana-ref}/settings.html[settings page].

[float]
[[memory]]
=== Memory

Kibana has a default memory limit that scales based on total memory available.  In some scenarios, such as large reporting jobs,
it may make sense to tweak limits to meet more specific requirements.

A limit can be defined by setting `--max-old-space-size` in the `node.options` config file found inside the `kibana/config` folder or any other folder configured with the environment variable `KBN_PATH_CONF`. For example, in the Debian-based system, the folder is `/etc/kibana`.

The option accepts a limit in MB:
[source,js]
--------
--max-old-space-size=2048
--------

[float]
[[openssl-legacy-provider]]
=== OpenSSL Legacy Provider

Starting in 8.10.0, {kib} has upgraded its runtime environment, Node.js, from version 16 to version 18 and with it the underlying version of OpenSSL to version 3.
Algorithms deemed legacy by OpenSSL 3 have been re-enabled to avoid potential breaking changes in a minor version release of {kib}.
If SSL certificates configured for {kib} are not using any of the legacy algorithms mentioned in the https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html[OpenSSL legacy provider documentation],
we recommend disabling this setting by removing `--openssl-legacy-provider` in the `node.options` config file.
