[Docs] Includes information about available index settings in Serverless (#129704)

* index settings for serverless information added

* comment removed

* Apply suggestions from code review

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>

* serverless applies removed from coerce doc

* eck applies addded to config reference landing

* toc updated

* index settings landing page aligned with toc

* serverless doc intro updated

---------

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>

docs/reference/elasticsearch/configuration-reference/data-stream-lifecycle-settings.md

@@ -3,8 +3,7 @@ navigation_title: "Data stream lifecycle settings"
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/data-stream-lifecycle-settings.html
 applies_to:
-  deployment:
-    self:
+  stack: all
 ---
 
 # Data stream lifecycle settings in {{es}} [data-stream-lifecycle-settings]
@@ -58,21 +57,24 @@ $$$data-streams-lifecycle-signalling-error-retry-interval$$$
 
 ## Index level settings [_index_level_settings]
 
+:::{include} ../index-settings/_snippets/serverless-availability.md
+:::
+
 The following index-level settings are typically configured on the backing indices of a data stream.
 
 $$$index-lifecycle-prefer-ilm$$$
 
 `index.lifecycle.prefer_ilm`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), boolean) This setting determines which feature is managing the backing index of a data stream if, and only if, the backing index has an [{{ilm}}](docs-content://manage-data/lifecycle/index-lifecycle-management.md) ({{ilm-init}}) policy and the data stream has also a built-in lifecycle. When `true` this index is managed by {{ilm-init}}, when `false` the backing index is managed by the data stream lifecycle. Defaults to `true`.
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), boolean) This setting determines which feature is managing the backing index of a data stream if, and only if, the backing index has an [{{ilm}}](docs-content://manage-data/lifecycle/index-lifecycle-management.md) ({{ilm-init}}) policy and the data stream has also a built-in lifecycle. When `true` this index is managed by {{ilm-init}}, when `false` the backing index is managed by the data stream lifecycle. Defaults to `true`.
 
 $$$index-data-stream-lifecycle-origination-date$$$
 
-`index.lifecycle.origination_date`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), long) If specified, this is the timestamp used to calculate the backing index generation age after this backing index has been [rolled over](docs-content://manage-data/lifecycle/index-lifecycle-management/rollover.md). The generation age is used to determine data retention, consequently, you can use this setting if you create a backing index that contains older data and want to ensure that the retention period or other parts of the lifecycle will be applied based on the data’s original timestamp and not the timestamp they got indexed. Specified as a Unix epoch value in milliseconds.
+`index.lifecycle.origination_date` {applies_to}`serverless: all`
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), long) If specified, this is the timestamp used to calculate the backing index generation age after this backing index has been [rolled over](docs-content://manage-data/lifecycle/index-lifecycle-management/rollover.md). The generation age is used to determine data retention, consequently, you can use this setting if you create a backing index that contains older data and want to ensure that the retention period or other parts of the lifecycle will be applied based on the data’s original timestamp and not the timestamp they got indexed. Specified as a Unix epoch value in milliseconds.
 
 ## Reindex settings [reindex-data-stream-settings]
 
-You can use the following settings to control the behavior of the reindex data stream API:
+You can use the following cluster-level settings to control the behavior of the reindex data stream API:
 
 `migrate.max_concurrent_indices_reindexed_per_data_stream` ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting)) The number of backing indices within a given data stream which will be reindexed concurrently. Defaults to `1`.
 

docs/reference/elasticsearch/configuration-reference/index-lifecycle-management-settings.md

@@ -3,8 +3,7 @@ navigation_title: "{{ilm-cap}} settings"
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-settings.html
 applies_to:
-  deployment:
-    self:
+  stack: all
 ---
 
 # {{ilm-cap}} settings in {{es}} [ilm-settings]
@@ -37,34 +36,37 @@ $$$indices-lifecycle-rollover-only-if-has-documents$$$
 
 ## Index level settings [_index_level_settings_2]
 
+:::{include} ../index-settings/_snippets/serverless-availability.md
+:::
+
 These index-level {{ilm-init}} settings are typically configured through index templates. For more information, see [Create a lifecycle policy](docs-content://manage-data/lifecycle/index-lifecycle-management/tutorial-automate-rollover.md#ilm-gs-create-policy).
 
 `index.lifecycle.indexing_complete`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), Boolean) Indicates whether or not the index has been rolled over. Automatically set to `true` when {{ilm-init}} completes the rollover action. You can explicitly set it to [skip rollover](docs-content://manage-data/lifecycle/index-lifecycle-management/skip-rollover.md). Defaults to `false`.
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), Boolean) Indicates whether or not the index has been rolled over. Automatically set to `true` when {{ilm-init}} completes the rollover action. You can explicitly set it to [skip rollover](docs-content://manage-data/lifecycle/index-lifecycle-management/skip-rollover.md). Defaults to `false`.
 
 $$$index-lifecycle-name$$$
 
 `index.lifecycle.name`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), string) The name of the policy to use to manage the index. For information about how {{es}} applies policy changes, see [Policy updates](docs-content://manage-data/lifecycle/index-lifecycle-management/policy-updates.md). If you are restoring an index from snapshot that was previously managed by {{ilm}}, you can override this setting to null during the restore operation to disable further management of the index. See also [Index level settings](#index-lifecycle-rollover-alias).
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), string) The name of the policy to use to manage the index. For information about how {{es}} applies policy changes, see [Policy updates](docs-content://manage-data/lifecycle/index-lifecycle-management/policy-updates.md). If you are restoring an index from snapshot that was previously managed by {{ilm}}, you can override this setting to null during the restore operation to disable further management of the index. See also [Index level settings](#index-lifecycle-rollover-alias).
 
 $$$index-lifecycle-origination-date$$$
 
-`index.lifecycle.origination_date`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), long) If specified, this is the timestamp used to calculate the index age for its phase transitions. Use this setting if you create a new index that contains old data and want to use the original creation date to calculate the index age. Specified as a Unix epoch value in milliseconds.
+`index.lifecycle.origination_date` {applies_to}`serverless: all`
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), long) If specified, this is the timestamp used to calculate the index age for its phase transitions. Use this setting if you create a new index that contains old data and want to use the original creation date to calculate the index age. Specified as a Unix epoch value in milliseconds.
 
 $$$index-lifecycle-parse-origination-date$$$
 
 `index.lifecycle.parse_origination_date`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), Boolean) Set to `true` to parse the origination date from the index name. This origination date is used to calculate the index age for its phase transitions. The index name must match the pattern `^.*-{{date_format}}-\\d+`, where the `date_format` is `yyyy.MM.dd` and the trailing digits are optional. An index that was rolled over would normally match the full format, for example `logs-2016.10.31-000002`). If the index name doesn’t match the pattern, index creation fails.
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), Boolean) Set to `true` to parse the origination date from the index name. This origination date is used to calculate the index age for its phase transitions. The index name must match the pattern `^.*-{{date_format}}-\\d+`, where the `date_format` is `yyyy.MM.dd` and the trailing digits are optional. An index that was rolled over would normally match the full format, for example `logs-2016.10.31-000002`). If the index name doesn’t match the pattern, index creation fails.
 
 $$$index-lifecycle-step-wait-time-threshold$$$
 
 `index.lifecycle.step.wait_time_threshold`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), [time value](/reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Time to wait for the cluster to resolve allocation issues during an {{ilm-init}} [`shrink`](/reference/elasticsearch/index-lifecycle-actions/ilm-shrink.md) action. Must be greater than `1h` (1 hour). Defaults to `12h` (12 hours). See [Shard allocation for shrink](/reference/elasticsearch/index-lifecycle-actions/ilm-shrink.md#ilm-shrink-shard-allocation).
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), [time value](/reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Time to wait for the cluster to resolve allocation issues during an {{ilm-init}} [`shrink`](/reference/elasticsearch/index-lifecycle-actions/ilm-shrink.md) action. Must be greater than `1h` (1 hour). Defaults to `12h` (12 hours). See [Shard allocation for shrink](/reference/elasticsearch/index-lifecycle-actions/ilm-shrink.md#ilm-shrink-shard-allocation).
 
 $$$index-lifecycle-rollover-alias$$$
 
 `index.lifecycle.rollover_alias`
-:   ([Dynamic](docs-content://deploy-manage/stack-settings.md#dynamic-cluster-setting), string) The index alias to update when the index rolls over. Specify when using a policy that contains a rollover action. When the index rolls over, the alias is updated to reflect that the index is no longer the write index. For more information about rolling indices, see [Rollover](docs-content://manage-data/lifecycle/index-lifecycle-management/rollover.md). If you are restoring an index from snapshot that was previously managed by {{ilm}}, you can override this setting to null during the restore operation to disable further management of future indices. See also [Index level settings](#index-lifecycle-name).
+:   ([Dynamic](../index-settings/index.md#index-modules-settings-description), string) The index alias to update when the index rolls over. Specify when using a policy that contains a rollover action. When the index rolls over, the alias is updated to reflect that the index is no longer the write index. For more information about rolling indices, see [Rollover](docs-content://manage-data/lifecycle/index-lifecycle-management/rollover.md). If you are restoring an index from snapshot that was previously managed by {{ilm}}, you can override this setting to null during the restore operation to disable further management of future indices. See also [Index level settings](#index-lifecycle-name).
 
 

docs/reference/elasticsearch/configuration-reference/index.md

@@ -5,6 +5,7 @@ applies_to:
     ess:
     ece:
     self:
+    eck:
   serverless:
 ---
 

docs/reference/elasticsearch/index-settings/_snippets/serverless-availability.md

@@ -0,0 +1,3 @@
+::::{admonition} Settings supported in Serverless
+{{serverless-full}} projects [restrict the available Elasticsearch settings](docs-content://deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md#elasticsearch-differences-serverless-settings-availability) to a supported subset, identified with a `Serverless` badge next to the setting name. For a complete list of available index settings, refer to the [Serverless index settings list](/reference/elasticsearch/index-settings/serverless.md).
+::::

docs/reference/elasticsearch/index-settings/data-tier-allocation.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/data-tier-shard-filtering.html
 navigation_title: Data tier allocation
+applies_to:
+  stack: all
 ---
 
 # Data tier allocation settings [data-tier-shard-filtering]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 You can use the index-level `_tier_preference` setting to control which [data tier](docs-content://manage-data/lifecycle/data-tiers.md) an index is allocated to.
 
 This setting corresponds to the data node roles:

docs/reference/elasticsearch/index-settings/history-retention.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-history-retention.html
 navigation_title: History retention
+applies_to:
+  stack: all
 ---
 
 # History retention settings [index-modules-history-retention]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 {{es}} sometimes needs to replay some of the operations that were performed on a shard. For instance, if a replica is briefly offline then it may be much more efficient to replay the few operations it missed while it was offline than to rebuild it from scratch. Similarly, {{ccr}} works by performing operations on the leader cluster and then replaying those operations on the follower cluster.
 
 At the Lucene level there are really only two write operations that {{es}} performs on an index: a new document may be indexed, or an existing document may be deleted. Updates are implemented by atomically deleting the old document and then indexing the new document. A document indexed into Lucene already contains all the information needed to replay that indexing operation, but this is not true of document deletions. To solve this, {{es}} uses a feature called *soft deletes* to preserve recent deletions in the Lucene index so that they can be replayed.

docs/reference/elasticsearch/index-settings/index-block.md

@@ -1,10 +1,15 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-blocks.html
-navigation_title: Index block
+navigation_title: Index blocks
+applies_to:
+  stack: all
 ---
 
-# Index block settings [index-modules-blocks]
+# Index blocks [index-modules-blocks]
+
+:::{include} _snippets/serverless-availability.md
+:::
 
 Index blocks limit the kind of operations that are available on a certain index. The blocks come in different flavours, allowing to block write, read, or metadata operations. The blocks can be set / removed using dynamic index settings, or can be added using a dedicated API, which also ensures for write blocks that, once successfully returning to the user, all shards of the index are properly accounting for the block, for example that all in-flight writes to an index have been completed after adding the write block.
 
@@ -15,7 +20,7 @@ The following *dynamic* index settings determine the blocks present on an index:
 
 $$$index-blocks-read-only$$$
 
-`index.blocks.read_only`
+`index.blocks.read_only` {applies_to}`serverless: all`
 :   Set to `true` to make the index and index metadata read only, `false` to allow writes and metadata changes.
 
 `index.blocks.read_only_allow_delete`
@@ -27,15 +32,16 @@ $$$index-blocks-read-only$$$
     {{es}} adds the read-only-allow-delete index block automatically when the disk utilization exceeds the flood stage watermark, and removes this block automatically when the disk utilization falls under the high watermark. See [Disk-based shard allocation](/reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#disk-based-shard-allocation) for more information about watermarks, and [Fix watermark errors](docs-content://troubleshoot/elasticsearch/fix-watermark-errors.md) for help with resolving watermark issues.
     ::::
 
-
-`index.blocks.read`
+$$$index-blocks-read$$$
+`index.blocks.read` {applies_to}`serverless: all`
 :   Set to `true` to disable read operations against the index.
 
 $$$index-blocks-write$$$
 
-`index.blocks.write`
+`index.blocks.write` {applies_to}`serverless: all`
 :   Set to `true` to disable data write operations against the index. Unlike `read_only`, this setting does not affect metadata. For instance, you can adjust the settings of an index with a `write` block, but you cannot adjust the settings of an index with a `read_only` block.
 
-`index.blocks.metadata`
+$$$index-blocks-metadata$$$
+`index.blocks.metadata` {applies_to}`serverless: all`
 :   Set to `true` to disable index metadata reads and writes.
 

docs/reference/elasticsearch/index-settings/index-modules.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html
 navigation_title: General
+applies_to:
+  stack: all
 ---
-# Index modules [index-modules]
+# General index settings [index-modules]
 
-Index modules are modules created per index and control all aspects related to an index.
+:::{include} _snippets/serverless-availability.md
+:::
+
+This document contains the static and dynamic index settings that are not associated with any specific index module.
 
 ## Static index settings [_static_index_settings]
 
@@ -44,10 +49,10 @@ In {{es}} 7.0.0 and later versions, this setting affects how documents are distr
 
 
 
-$$$index-codec$$$ `index.codec`
+$$$index-codec$$$ `index.codec` {applies_to}`serverless: all`
 :   The `default` value compresses stored data with LZ4 compression, but this can be set to `best_compression` which uses [ZSTD](https://en.wikipedia.org/wiki/Zstd) for a higher compression ratio, at the expense of slower stored fields read performance. If you are updating the compression type, the new one will be applied after segments are merged. Segment merging can be forced using [force merge](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-forcemerge). Experiments with indexing log datasets have shown that `best_compression` gives up to ~28% lower storage usage and similar indexing throughput (sometimes a bit slower or faster depending on other used options) compared to `default` while affecting get by id latencies between ~10% and ~33%. The higher get by id latencies is not a concern for many use cases like logging or metrics, since these don’t really rely on get by id functionality (Get APIs or searching by _id).
 
-$$$index-mode-setting$$$ `index.mode`
+$$$index-mode-setting$$$ `index.mode` {applies_to}`serverless: all`
 :   The `index.mode` setting is used to control settings applied in specific domains like ingestion of time series data or logs. Different mutually exclusive modes exist, which are used to apply settings or default values controlling indexing of documents, sorting and other parameters whose value affects indexing or query performance.
 
         **Example**
@@ -144,8 +149,10 @@ $$$dynamic-index-search-idle-after$$$
 
 $$$index-refresh-interval-setting$$$
 
-`index.refresh_interval`
-:   How often to perform a refresh operation, which makes recent changes to the index visible to search. Defaults to `1s`. Can be set to `-1` to disable refresh. If this setting is not explicitly set, shards that haven’t seen search traffic for at least `index.search.idle.after` seconds will not receive background refreshes until they receive a search request. Searches that hit an idle shard where a refresh is pending will trigger a refresh as part of the search operation for that shard only. This behavior aims to automatically optimize bulk indexing in the default case when no searches are performed. In order to opt out of this behavior an explicit value of `1s` should set as the refresh interval.
+`index.refresh_interval` {applies_to}`serverless: all`
+:   How often to perform a refresh operation, which makes recent changes to the index visible to search. If this setting is not explicitly set, shards that haven’t seen search traffic for at least `index.search.idle.after` seconds will not receive background refreshes until they receive a search request. Searches that hit an idle shard where a refresh is pending will trigger a refresh as part of the search operation for that shard only. This behavior aims to automatically optimize bulk indexing in the default case when no searches are performed. To opt out of this behavior, set an explicit value for the refresh interval, even if it matches the default value.
+
+    The value defaults to `1s` in {{stack}} and `5s` in {{serverless-short}}. In both cases, the setting can be set to `-1` to disable refresh.
 
 $$$index-max-result-window$$$
 
@@ -197,7 +204,7 @@ $$$index-max-regex-length$$$
 
 $$$index-query-default-field$$$
 
-`index.query.default_field`
+`index.query.default_field` {applies_to}`serverless: all`
 :   (string or array of strings) Wildcard (`*`) patterns matching one or more fields. The following query types search these matching fields by default:
 
 * [More like this](/reference/query-languages/query-dsl/query-dsl-mlt-query.md)
@@ -233,12 +240,12 @@ $$$index-routing-allocation-enable-setting$$$
 
 $$$index-default-pipeline$$$
 
-`index.default_pipeline`
+`index.default_pipeline` {applies_to}`serverless: all`
 :   Default ingest pipeline for the index. Index requests will fail if the default pipeline is set and the pipeline does not exist. The default may be overridden using the `pipeline` parameter. The special pipeline name `_none` indicates no default ingest pipeline will run.
 
 $$$index-final-pipeline$$$
 
-`index.final_pipeline`
+`index.final_pipeline` {applies_to}`serverless: all`
 :   Final ingest pipeline for the index. Indexing requests will fail if the final pipeline is set and the pipeline does not exist. The final pipeline always runs after the request pipeline (if specified) and the default pipeline (if it exists). The special pipeline name `_none` indicates no final ingest pipeline will run.
 
     ::::{note}
@@ -246,10 +253,10 @@ $$$index-final-pipeline$$$
     ::::
 
 
-$$$index-hidden$$$ `index.hidden`
+$$$index-hidden$$$ `index.hidden` {applies_to}`serverless: all`
 :   Indicates whether the index should be hidden by default. Hidden indices are not returned by default when using a wildcard expression. This behavior is controlled per request through the use of the `expand_wildcards` parameter. Possible values are `true` and `false` (default).
 
-$$$index-dense-vector-hnsw-filter-heuristic$$$ `index.dense_vector.hnsw_filter_heuristic`
+$$$index-dense-vector-hnsw-filter-heuristic$$$ `index.dense_vector.hnsw_filter_heuristic` {applies_to}`serverless: all`
 :   The heuristic to utilize when executing a filtered search against vectors in an HNSW graph. This setting is in technical preview may be changed or removed in a future release. It can be set to:
 
 * `acorn` (default) - Only vectors that match the filter criteria are searched. This is the fastest option, and generally provides faster searches at similar recall to `fanout`, but `num_candidates` might need to be increased for exceptionally high recall requirements.

docs/reference/elasticsearch/index-settings/index.md

@@ -1,7 +1,16 @@
+---
+applies_to:
+  stack: all
+---
 # Index settings
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 $$$index-modules-settings-description$$$
-Index level settings can be set per-index. Settings may be:
+{{es}} organizes index-level settings into index modules, each controlling a specific aspect of index behavior.
+
+These settings are configured on a per-index basis and may be:
 
 * _Static_
   They can only be set at index creation time or on a closed index, or by using the [update index settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-put-settings) with the `reopen` query parameter set to `true` (which automatically closes and reopens impacted indices).
@@ -14,25 +23,31 @@ You can change any documented index settings on closed indices. However, changin
 
 Settings are available for the following modules:
 
-* [History retention](history-retention.md)
-  Control the retention of a history of operations in the index.
-* [Index](index-modules.md)
-  General settings that affect the behavior of indices.
-* [Index shard allocation](shard-allocation.md)
+* [General](index-modules.md):
+  Index settings not tied to a specific module.
+* [Index shard allocation](shard-allocation.md):
   Control where, when, and how shards are allocated to nodes.
-* [Indexing pressure](pressure.md)
-  Configure indexing back pressure limits.
-* [Merge](merge.md)
+* [History retention](history-retention.md)
+  Control how long the history of operations is retained in the index.
+* [Index blocks](./index-block.md):
+  Block different type of operations to the indices.
+* [Mapping limits](./mapping-limit.md):
+  Limit the number of field mappings.
+* [Merge](merge.md):
   Control how shards are merged by the background merge process.
-* [Similarities](similarity.md)
+* [Similarities](similarity.md):
   Configure custom similarity settings to customize how search results are scored.
-* [Slowlog](slow-log.md)
+* [Slowlog](slow-log.md):
   Control how slow queries and fetch requests are logged.
-* [Store](store.md)
+* [Sorting](./sorting.md):
+  Configure how to sort the segments inside each shard.
+* [Store](store.md):
   Configure the type of filesystem used to access shard data.
 * [Time series](time-series.md)
   Configure the backing indices in a time series data stream (TSDS).
 * [Translog](translog.md)
   Control the transaction log and background flush operations.
+* [Indexing pressure](pressure.md)
+  Configure indexing back pressure limits.
 
 There are also index settings associated with [text analysis](docs-content://manage-data/data-store/text-analysis.md), which define analyzers, tokenizers, token filters, and character filters.

docs/reference/elasticsearch/index-settings/mapping-limit.md

@@ -2,13 +2,19 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-settings-limit.html
 navigation_title: Mapping limit
+applies_to:
+  stack: all
 ---
 
 # Mapping limit settings [mapping-settings-limit]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 Use the following settings to limit the number of field mappings (created manually or dynamically) and prevent documents from causing a mapping explosion:
 
-`index.mapping.total_fields.limit`
+$$$total-fields-limit$$$
+`index.mapping.total_fields.limit` {applies_to}`serverless: all`
 :   The maximum number of fields in an index. Field and object mappings, as well as field aliases count towards this limit. Mapped runtime fields count towards this limit as well. The default value is `1000`.
 
     ::::{important}
@@ -24,8 +30,8 @@ Use the following settings to limit the number of field mappings (created manual
 
     ::::
 
-
-`index.mapping.total_fields.ignore_dynamic_beyond_limit`
+$$$ignore-dynamic-beyond-limit$$$
+`index.mapping.total_fields.ignore_dynamic_beyond_limit` {applies_to}`serverless: all`
 :   This setting determines what happens when a dynamically mapped field would exceed the total fields limit. When set to `false` (the default), the index request of the document that tries to add a dynamic field to the mapping will fail with the message `Limit of total fields [X] has been exceeded`. When set to `true`, the index request will not fail. Instead, fields that would exceed the limit are not added to the mapping, similar to [`dynamic: false`](/reference/elasticsearch/mapping-reference/dynamic.md). The fields that were not added to the mapping will be added to the [`_ignored` field](/reference/elasticsearch/mapping-reference/mapping-ignored-field.md). The default value is `false`.
 
 `index.mapping.depth.limit`

docs/reference/elasticsearch/index-settings/merge.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html
 navigation_title: Merge
+applies_to:
+  stack: all
 ---
 
 # Merge settings [index-modules-merge]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 A shard in Elasticsearch is a Lucene index, and a Lucene index is broken down into segments. Segments are internal storage elements in the index where the index data is stored, and are immutable. Smaller segments are periodically merged into larger segments to keep the index size at bay and to expunge deletes.
 
 The merge process uses auto-throttling to balance the use of hardware resources between merging and other activities like search.

docs/reference/elasticsearch/index-settings/preloading-data-into-file-system-cache.md

@@ -1,10 +1,15 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/preload-data-to-file-system-cache.html
+applies_to:
+  stack: all
 ---
 
 # Preloading data into the file system cache [preload-data-to-file-system-cache]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 ::::{note}
 This is an expert setting, the details of which may change in the future.
 ::::

docs/reference/elasticsearch/index-settings/recovery-prioritization.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/recovery-prioritization.html
 navigation_title: Index recovery prioritization
+applies_to:
+  stack: all
 ---
 
 # Index recovery prioritization settings [recovery-prioritization]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 Unallocated shards are recovered in order of priority, whenever possible. Indices are sorted into priority order as follows:
 
 * the optional `index.priority` setting (higher before lower)

docs/reference/elasticsearch/index-settings/serverless.md

@@ -0,0 +1,63 @@
+---
+navigation_title: Serverless index settings
+applies_to:
+  serverless: all
+---
+
+# Index settings available in {{serverless-full}} projects
+
+In {{serverless-full}} projects, configuration available to users is [limited](docs-content://deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md#elasticsearch-differences-serverless-settings-availability) to certain index-level settings. These restrictions help ensure the reliability of {{serverless-short}} projects.
+
+This page lists the {{es}} index settings available in {{serverless-full}} projects.
+
+### General settings
+
+* [`index.codec`](./index-modules.md#index-codec)
+* [`index.default_pipeline`](./index-modules.md#index-default-pipeline)  
+* [`index.dense_vector.hnsw_filter_heuristic`](./index-modules.md#index-dense-vector-hnsw-filter-heuristic)
+* [`index.final_pipeline`](./index-modules.md#index-final-pipeline)  
+* [`index.hidden`](./index-modules.md#index-hidden)
+* [`index.mode`](./index-modules.md#index-mode-setting)
+* [`index.query.default_field`](./index-modules.md#index-query-default-field)  
+* [`index.refresh_interval`](./index-modules.md#index-refresh-interval-setting)  
+
+### Index sorting settings
+
+* [`index.sort.field`](./sorting.md#index-sort-field)
+* [`index.sort.missing`](./sorting.md#index-sort-missing)
+* [`index.sort.mode`](./sorting.md#index-sort-mode)
+* [`index.sort.order`](./sorting.md#index-sort-order)
+
+### Index blocks settings
+
+* [`index.blocks.read_only`](./index-block.md#index-blocks-read-only)  
+* [`index.blocks.read`](./index-block.md#index-blocks-read)  
+* [`index.blocks.write`](./index-block.md#index-blocks-write)  
+* [`index.blocks.metadata`](./index-block.md#index-blocks-metadata)  
+
+### Field and mapping related settings
+
+* [`index.mapping.coerce`](../mapping-reference/coerce.md#coerce-setting)
+* [`index.mapping.ignore_above`](../mapping-reference/index-mapping-ignore-above.md)
+* [`index.mapping.ignore_malformed`](../mapping-reference/ignore-malformed.md#ignore-malformed-setting)
+* [`index.mapping.source.mode`](../mapping-reference/mapping-source-field.md)
+* [`index.mapping.synthetic_source_keep`](../mapping-reference/mapping-source-field.md)
+* [`index.mapping.total_fields.limit`](./mapping-limit.md#total-fields-limit)
+* [`index.mapping.total_fields.ignore_dynamic_beyond_limit`](./mapping-limit.md#ignore-dynamic-beyond-limit)
+
+### Data stream lifecycle settings
+
+* [`index.lifecycle.origination_date`](../configuration-reference/data-stream-lifecycle-settings.md#index-data-stream-lifecycle-origination-date)
+
+### Time series settings
+
+* [`index.time_series.start_time`](./time-series.md#index-time-series-start-time)
+* [`index.time_series.end_time`](./time-series.md#index-time-series-end-time)
+* [`index.look_ahead_time`](./time-series.md#index-look-ahead-time)
+* [`index.look_back_time`](./time-series.md#index-look-back-time)
+* [`index.routing_path`](./time-series.md#index-routing-path)
+
+### Similarity and analyzers
+
+* [`index.similarity.*`](../mapping-reference/similarity.md)
+* [`index.analysis.*`](../mapping-reference/analyzer.md)

docs/reference/elasticsearch/index-settings/shard-allocation.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation-filtering.html
 navigation_title: Shard allocation
+applies_to:
+  stack: all
 ---
 
 # Index-level shard allocation settings [shard-allocation-filtering]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 You can use shard allocation filters to control where {{es}} allocates shards of a particular index. These per-index filters are applied in conjunction with [cluster-wide allocation filtering](/reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#cluster-shard-allocation-filtering) and [allocation awareness](docs-content://deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness.md).
 
 Shard allocation filters can be based on [custom node attributes](/reference/elasticsearch/configuration-reference/node-settings.md#custom-node-attributes) or the built-in `_name`, `_host_ip`, `_publish_ip`, `_ip`, `_host`, `_id`, `_tier` and `_tier_preference` attributes. [Index lifecycle management](docs-content://manage-data/lifecycle/index-lifecycle-management.md) uses filters based on custom node attributes to determine how to reallocate shards when moving between phases.

docs/reference/elasticsearch/index-settings/similarity.md

@@ -2,6 +2,9 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-similarity.html
 navigation_title: Similarity
+applies_to:
+  stack: all
+  serverless: all
 ---
 
 # Similarity settings [index-modules-similarity]

docs/reference/elasticsearch/index-settings/slow-log.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-slowlog.html
 navigation_title: Slow log
+applies_to:
+  stack: all
 ---
 
 # Slow log settings [index-modules-slowlog]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 The slow log records database searching and indexing events that have execution durations above specified thresholds. You can use these logs to investigate analyze or troubleshoot your cluster’s historical search and indexing performance.
 
 Slow logs report task duration at the shard level for searches, and at the index level for indexing, but might not encompass the full task execution time observed on the client. For example, slow logs don’t surface HTTP network delays or the impact of [task queues](docs-content://troubleshoot/elasticsearch/task-queue-backlog.md). For more information about the higher-level operations affecting response times, refer to [Reading and writing documents](docs-content://deploy-manage/distributed-architecture/reading-and-writing-documents.md).

docs/reference/elasticsearch/index-settings/sorting-conjunctions.md

@@ -1,6 +1,9 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-index-sorting-conjunctions.html
+applies_to:
+  stack: all
+  serverless: all
 ---
 
 # Use index sorting to speed up conjunctions [index-modules-index-sorting-conjunctions]

docs/reference/elasticsearch/index-settings/sorting.md

@@ -2,6 +2,9 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-index-sorting.html
 navigation_title: Sorting
+applies_to:
+  stack: all
+  serverless: all
 ---
 
 # Index sorting settings [index-modules-index-sorting]
@@ -35,7 +38,7 @@ PUT my-index-000001
 ```
 
 1. This index is sorted by the `date` field
-2. …  in descending order.
+2. In descending order.
 
 
 It is also possible to sort the index by more than one field:
@@ -64,29 +67,32 @@ PUT my-index-000001
 ```
 
 1. This index is sorted by `username` first then by `date`
-2. …  in ascending order for the `username` field and in descending order for the `date` field.
+2. In ascending order for the `username` field and in descending order for the `date` field.
 
 
 Index sorting supports the following settings:
 
-`index.sort.field`
+$$$index-sort-field$$$
+`index.sort.field` {applies_to}`serverless: all`
 :   The list of fields used to sort the index. Only `boolean`, `numeric`, `date` and `keyword` fields with `doc_values` are allowed here.
 
-`index.sort.order`
+$$$index-sort-order$$$
+`index.sort.order` {applies_to}`serverless: all`
 :   The sort order to use for each field. The order option can have the following values:
 
     * `asc`:  For ascending order
     * `desc`: For descending order.
 
-
-`index.sort.mode`
+$$$index-sort-mode$$$
+`index.sort.mode` {applies_to}`serverless: all`
 :   Elasticsearch supports sorting by multi-valued fields. The mode option controls what value is picked to sort the document. The mode option can have the following values:
 
     * `min`: 	Pick the lowest value.
     * `max`: 	Pick the highest value.
 
 
-`index.sort.missing`
+$$$index-sort-missing$$$
+`index.sort.missing` {applies_to}`serverless: all`
 :   The missing parameter specifies how docs which are missing the field should be treated. The missing value can have the following values:
 
     * `_last`: Documents without value for the field are sorted last.

docs/reference/elasticsearch/index-settings/store.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html
 navigation_title: Store
+applies_to:
+  stack: all
 ---
 
 # Index store settings [index-modules-store]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 The store module allows you to control how index data is stored and accessed on disk.
 
 ::::{note}

docs/reference/elasticsearch/index-settings/time-series.md

@@ -2,30 +2,35 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds-index-settings.html
 navigation_title: Time series
+applies_to:
+  stack: all
 ---
 
 # Time series index settings [tsds-index-settings]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 Backing indices in a [time series data stream (TSDS)](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md) support the following index settings.
 
 $$$index-mode$$$
 
-`index.mode`
+`index.mode` {applies_to}`serverless: all`
 :   (Static, string) Mode for the index. Valid values are [`time_series`](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#time-series-mode) and `null` (no mode). Defaults to `null`.
 
 $$$index-time-series-start-time$$$
 
-`index.time_series.start_time`
+`index.time_series.start_time` {applies_to}`serverless: all`
 :   (Static, string) Earliest `@timestamp` value (inclusive) accepted by the index. Only indices with an `index.mode` of [`time_series`](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#time-series-mode) support this setting. For more information, refer to [Time-bound indices](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#time-bound-indices).
 
 $$$index-time-series-end-time$$$
 
-`index.time_series.end_time`
+`index.time_series.end_time` {applies_to}`serverless: all`
 :   (Dynamic, string) Latest `@timestamp` value (exclusive) accepted by the index. Only indices with an `index.mode` of `time_series` support this setting. For more information, refer to [Time-bound indices](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#time-bound-indices).
 
 $$$index-look-ahead-time$$$
 
-`index.look_ahead_time`
+`index.look_ahead_time` {applies_to}`serverless: all`
 :   (Static, [time units](/reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Interval used to calculate the `index.time_series.end_time` for a TSDS’s write index. Defaults to `30m` (30 minutes). Accepts `1m` (one minute) to `2h` (two hours). Only indices with an `index.mode` of `time_series` support this setting. For more information, refer to [Look-ahead time](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#tsds-look-ahead-time). Additionally this setting can not be less than `time_series.poll_interval` cluster setting.
 
 ::::{note}
@@ -35,10 +40,10 @@ Increasing the `look_ahead_time` will also increase the amount of time {{ilm-cap
 
 $$$index-look-back-time$$$
 
-`index.look_back_time`
+`index.look_back_time` {applies_to}`serverless: all`
 :   (Static, [time units](/reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Interval used to calculate the `index.time_series.start_time` for a TSDS’s first backing index when a tsdb data stream is created. Defaults to `2h` (2 hours). Accepts `1m` (one minute) to `7d` (seven days). Only indices with an `index.mode` of `time_series` support this setting. For more information, refer to [Look-back time](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#tsds-look-back-time).
 
-$$$index-routing-path$$$ `index.routing_path`
+$$$index-routing-path$$$ `index.routing_path` {applies_to}`serverless: all`
 :   (Static, string or array of strings) Plain `keyword` fields used to route documents in a TSDS to index shards. Supports wildcards (`*`). Only indices with an `index.mode` of `time_series` support this setting. Defaults to an empty list, except for data streams then defaults to the list of [dimension fields](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#time-series-dimension) with a `time_series_dimension` value of `true` defined in your component and index templates. For more information, refer to [Dimension-based routing](docs-content://manage-data/data-store/data-streams/time-series-data-stream-tsds.md#dimension-based-routing).
 
 $$$index-mapping-dimension-fields-limit$$$

docs/reference/elasticsearch/index-settings/total-shards-per-node.md

@@ -1,10 +1,15 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-total-shards.html
+applies_to:
+  stack: all
 ---
 
 # Total shards per node [allocation-total-shards]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 The cluster-level shard allocator tries to spread the shards of a single index across as many nodes as possible. However, depending on how many shards and indices you have, and how big they are, it may not always be possible to spread shards evenly.
 
 The following *dynamic* setting allows you to specify a hard limit on the total number of shards from a single index allowed per node:

docs/reference/elasticsearch/index-settings/translog.md

@@ -2,10 +2,15 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html
 navigation_title: Translog
+applies_to:
+  stack: all
 ---
 
 # Translog settings [index-modules-translog]
 
+:::{include} _snippets/serverless-availability.md
+:::
+
 Changes to Lucene are only persisted to disk during a Lucene commit, which is a relatively expensive operation and so cannot be performed after every index or delete operation. Changes that happen after one commit and before another will be removed from the index by Lucene in the event of process exit or hardware failure.
 
 Lucene commits are too expensive to perform on every individual change, so each shard copy also writes operations into its *transaction log* known as the *translog*. All index and delete operations are written to the translog after being processed by the internal Lucene index but before they are acknowledged. In the event of a crash, recent operations that have been acknowledged but not yet included in the last Lucene commit are instead recovered from the translog when the shard recovers.

docs/reference/elasticsearch/mapping-reference/analyzer.md

@@ -1,13 +1,15 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/analyzer.html
+applies_to:
+   stack: all
+   serverless: all
 ---
 
 # analyzer [analyzer]
 
 ::::{important}
 Only [`text`](/reference/elasticsearch/mapping-reference/text.md) fields support the `analyzer` mapping parameter.
-
 ::::
 
 
@@ -17,7 +19,6 @@ Unless overridden with the [`search_analyzer`](/reference/elasticsearch/mapping-
 
 ::::{tip}
 We recommend testing analyzers before using them in production. See [Test an analyzer](docs-content://manage-data/data-store/text-analysis/test-an-analyzer.md).
-
 ::::
 
 

docs/reference/elasticsearch/mapping-reference/coerce.md

@@ -1,6 +1,9 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/coerce.html
+applies_to:
+  stack: all
+  serverless: all
 ---
 
 # coerce [coerce]

docs/reference/elasticsearch/mapping-reference/ignore-malformed.md

@@ -1,6 +1,9 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-malformed.html
+applies_to:
+  stack: all
+  serverless: all
 ---
 
 # ignore_malformed [ignore-malformed]

docs/reference/elasticsearch/mapping-reference/index-mapping-ignore-above.md

@@ -1,13 +1,16 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-mapping-ignore-above.html
+applies_to:
+  stack: all
+  serverless: all
 ---
 
-# index.mapping.ignore_above [index-mapping-ignore-above]
+# ignore_above index setting [index-mapping-ignore-above]
 
-The `ignore_above` setting, typically used at the field level, can also be applied at the index level using `index.mapping.ignore_above`. This setting lets you define a maximum string length for all applicable fields across the index, including `keyword`, `wildcard`, and keyword values in `flattened` fields. Any values that exceed this limit will be ignored during indexing and won’t be stored.
+The [`ignore_above` field-level setting](./ignore-above.md) can also be applied at the index level using `index.mapping.ignore_above`. This setting lets you define a maximum string length for all applicable fields across the index, including `keyword`, `wildcard`, and keyword values in `flattened` fields. Any values that exceed this limit will be [ignored](./mapping-ignored-field.md) during indexing and won’t be stored.
 
-This index-wide setting ensures a consistent approach to managing excessively long values. It works the same as the field-level setting—if a string’s length goes over the specified limit, that string won’t be indexed or stored. When dealing with arrays, each element is evaluated separately, and only the elements that exceed the limit are ignored.
+This index-level setting ensures a consistent approach to managing excessively long values. It works the same as the field-level setting—if a string’s length goes over the specified limit, that string won’t be indexed or stored. When dealing with arrays, each element is evaluated separately, and only the elements that exceed the limit are ignored.
 
 ```console
 PUT my-index-000001

docs/reference/elasticsearch/mapping-reference/mapping-source-field.md

@@ -1,6 +1,9 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html
+applies_to:
+  stack: all
+  serverless: all
 ---
 
 # _source field [mapping-source-field]
@@ -48,7 +51,7 @@ For all other field types, the original value of the field is stored as is, in t
 
 Some field types have additional restrictions. These restrictions are documented in the **synthetic `_source`** section of the field type’s [documentation](/reference/elasticsearch/mapping-reference/field-data-types.md).
 
-Synthetic source is not supported in [source-only](docs-content://deploy-manage/tools/snapshot-and-restore/source-only-repository.md) snapshot repositories. To store indexes that use synthetic `_source`, choose a different repository type.
+Synthetic source is not supported in [source-only](docs-content://deploy-manage/tools/snapshot-and-restore/source-only-repository.md) snapshot repositories. To store indices that use synthetic `_source`, choose a different repository type.
 
 ### Synthetic `_source` modifications [synthetic-source-modifications]
 
@@ -320,7 +323,7 @@ Users often disable the `_source` field without thinking about the consequences,
 ::::
 
 ::::{note}
-You can't disable the `_source` field for indexes with [`index_mode`](/reference/elasticsearch/index-settings/index-modules.md#index-mode-setting) set to `logsdb` or `time_series`.
+You can't disable the `_source` field for indices with [`index_mode`](/reference/elasticsearch/index-settings/index-modules.md#index-mode-setting) set to `logsdb` or `time_series`.
 ::::
 
 

docs/reference/elasticsearch/toc.yml

@@ -36,18 +36,17 @@ toc:
   - file: security-privileges.md
   - file: index-settings/index.md
     children:
-        - file: index-settings/data-tier-allocation.md
+        - file: index-settings/serverless.md
         - file: index-settings/index-modules.md
+        - file: index-settings/shard-allocation.md
+          children:
+            - file: index-settings/data-tier-allocation.md
+            - file: index-settings/recovery-prioritization.md
+            - file: index-settings/total-shards-per-node.md
         - file: index-settings/history-retention.md
         - file: index-settings/index-block.md
-        - file: index-settings/recovery-prioritization.md
-        - file: index-settings/pressure.md
         - file: index-settings/mapping-limit.md
         - file: index-settings/merge.md
-        - file: index-settings/path.md
-        - file: index-settings/shard-allocation.md
-          children:
-            - file: index-settings/total-shards-per-node.md
         - file: index-settings/similarity.md
         - file: index-settings/slow-log.md
         - file: index-settings/sorting.md
@@ -58,6 +57,8 @@ toc:
             - file: index-settings/preloading-data-into-file-system-cache.md
         - file: index-settings/time-series.md
         - file: index-settings/translog.md
+        - file: index-settings/pressure.md
+        - file: index-settings/path.md
   - file: index-lifecycle-actions/index.md
     children:
         - file: index-lifecycle-actions/index.md