In Elastic Cloud Serverless, cluster-level settings and node-level settings are not required by end users, and are fully managed by Elastic.

Certainproject settings allow you to customize your project’s performance and general data retention, and enable or disable project features.

• Dynamic Elasticsearch cluster settings can also be updated using Elasticsearch'supdate cluster settings API. However, Elastic Cloud Hosted and Elastic Cloud Enterprise don’t reject unsafe setting changes made using this API, and should be used with caution in these contexts.
• If a feature requires both standardelasticsearch.yml settings andsecure settings, configure the secure settings first. Updating standard user settings can trigger a cluster rolling restart in self managed clusters and ECH and ECE deployments. If the required secure settings are not yet in place, the nodes might fail to start. Adding secure settings does not trigger a restart.

For Elastic Cloud Hosted and Elastic Cloud Enterprise deployments, you edit Elastic Stack settings through the Elastic Cloud Console or ECE Cloud UI. These settings are internally mapped to the appropriate YAML configuration files, such aselasticsearch.yml andkibana.yml, and they affect all users of that cluster.

Elastic Cloud Hosted and Elastic Cloud Enterprise block the configuration of certain settings that could break your cluster if misconfigured. If a setting is not supported, you will get an error message when you try to save. We suggest changing one setting with each save, so you know which one is not supported.

1. Log in to theElastic Cloud Console or ECECloud UI.

2. On the home page, find your deployment.

   Tip

   If you have many deployments, you can instead go to theHosted deployments (Elastic Cloud Hosted) orDeployments (Elastic Cloud Enterprise) page. On that page, you can narrow your deployments by name, ID, or choose from several other filters.

3. SelectManage.

4. Under the deployment's name in the navigation menu, selectEdit.
5. Look for theManage user settings and extensions andEdit user settings links for each deployment, and select the one corresponding to the component you want to update, such as Elasticsearch or Kibana.
6. Apply the necessary settings in theUsers Settings tab of the editor and selectBack when finished.
7. SelectSave to apply the changes to the deployment. Saving your changes initiates a configuration plan change that restarts the affected components for you.

For further details and examples, refer to the resource for your deployment type:

• Elastic Cloud Hosted
• Elastic Cloud Enterprise

Stack settings are defined as part of your resource specification.

Elasticsearch settings that are typically defined in theelasticsearch.yml configuration file can be specified for a set of nodes in thespec.nodeSets[?].config section of the Elasticsearch resource manifest.

Some settings are managed by ECK. It is not recommended to change these managed settings. For a complete list, refer toSettings managed by ECK.

spec:  nodeSets:  - name: masters    count: 3    config:      # On Elasticsearch versions before 7.9.0, replace the node.roles configuration with the following:      # node.master: true      node.roles: ["master"]      xpack.ml.enabled: true  - name: data    count: 10    config:      # On Elasticsearch versions before 7.9.0, replace the node.roles configuration with the following:      # node.master: false      # node.data: true      # node.ingest: true      # node.ml: true      # node.transform: true      node.roles: ["data", "ingest", "ml", "transform"]

spec:  nodeSets:  - name: data    # ...    config:      cluster.max_shards_per_node: 1000      cluster.max_shards_per_node.frozen: 1000    # ...

You can add your own Kibana settings to thespec.config section.

The following example demonstrates how to set theelasticsearch.requestHeadersWhitelist configuration option.

apiVersion: kibana.k8s.elastic.co/v1kind: Kibanametadata:  name: kibana-samplespec:  version: 9.3.0  count: 1  elasticsearchRef:    name: "elasticsearch-sample"  config:     elasticsearch.requestHeadersWhitelist:     - authorization

The method and location where you can update your Elastic Stack settings depends on the component and installation method.

Most settings can be changed on a running cluster using theCluster update settings API.

You can also set Elasticsearch settings inelasticsearch.yml. Some settings require a cluster restart. To learn more, refer toDynamic and static Elasticsearch settings.

To learn more about configuring Elasticsearch in a self-managed environment, refer toConfigure Elasticsearch.

To learn more about configuring Kibana in a self-managed environment, refer toConfigure Kibana.

For APM and Enterprise Search, refer to the product's documentation:

• APM
• Enterprise Search

Theelasticsearch.yml configuration format isYAML. Here is an example of changing the path of the data and logs directories in Elasticsearch:

path:    data: /var/lib/elasticsearch    logs: /var/log/elasticsearch

Settings can also be flattened as follows:

path.data: /var/lib/elasticsearchpath.logs: /var/log/elasticsearch

In YAML, you can format non-scalar values as sequences:

discovery.seed_hosts:   - 192.168.1.10:9300   - 192.168.1.11   - seeds.mydomain.com

Though less common, you can also format non-scalar values as arrays:

discovery.seed_hosts: ["192.168.1.10:9300", "192.168.1.11", "seeds.mydomain.com"]

Environment variables referenced with the${...} notation within theelasticsearch.yml configuration file will be replaced with the value of the environment variable. For example:

node.name:    ${HOSTNAME}network.host: ${ES_NETWORK_HOST}

Values for environment variables must be simple strings. Use a comma-separated string to provide values that the component will parse as a list. For example, Elasticsearch will split the following string into a list of values for the${HOSTNAME} environment variable:

export HOSTNAME="host1,host2"

By default, configuration validation will fail if an environment variable used in the config file is not present when the component starts. This behavior can be changed by using a default value for the environment variable, using the${MY_ENV_VAR:defaultValue} syntax.

We no longer recommend using transient cluster settings. Use persistent cluster settings instead. If a cluster becomes unstable, transient settings can clear unexpectedly, resulting in a potentially undesired cluster configuration.