> ## Documentation Index
> Fetch the complete documentation index at: https://developer.upsun.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Elasticsearch and Enterprise Search (search service)

> Add Elastic Enterprise Search to your Upsun project as a Premium service. Legacy Elasticsearch versions (up to 7.10) remain available but are at end of life.


export const DynamicCodeBlock = ({language = 'yaml', filename, icon, lines, wrap, expandable, highlight, focus, children}) => {
  const STORAGE_KEY = 'upsun_versions_cache';
  const COMPOSABLE_STORAGE_KEY = 'upsun_composable_cache';
  const CACHE_TTL = 5 * 60 * 1000;
  const API_URL = 'https://meta.upsun.com/images';
  const COMPOSABLE_API_URL = 'https://meta.upsun.com/composable';
  const DEBUG_PREFIX = '[DynamicCodeBlock cache]';
  const [versionData, setVersionData] = useState(null);
  const [versionError, setVersionError] = useState(false);
  const [composableData, setComposableData] = useState(null);
  const [composableError, setComposableError] = useState(false);
  useEffect(() => {
    const fetchData = async () => {
      let cachedData = null;
      let cachedEtag = null;
      if (typeof localStorage !== 'undefined') {
        try {
          const cached = localStorage.getItem(STORAGE_KEY);
          if (cached) {
            const parsed = JSON.parse(cached);
            cachedData = parsed?.data || null;
            cachedEtag = parsed?.etag || null;
            if (cachedData && Date.now() - parsed.timestamp < CACHE_TTL) {
              return cachedData;
            }
          }
        } catch (err) {
          console.error('Failed to load from cache:', err);
        }
      }
      const requestHeaders = cachedEtag ? {
        'If-None-Match': cachedEtag
      } : {};
      console.debug(`${DEBUG_PREFIX} revalidating`, {
        storageKey: STORAGE_KEY,
        hasCachedData: Boolean(cachedData),
        hasCachedEtag: Boolean(cachedEtag)
      });
      const response = await fetch(API_URL, {
        headers: requestHeaders
      });
      if (response.status === 304 && cachedData) {
        console.debug(`${DEBUG_PREFIX} revalidated (304)`, {
          storageKey: STORAGE_KEY
        });
        if (typeof localStorage !== 'undefined') {
          try {
            const etag = response.headers.get('etag') || cachedEtag;
            localStorage.setItem(STORAGE_KEY, JSON.stringify({
              data: cachedData,
              etag,
              timestamp: Date.now()
            }));
          } catch (err) {
            console.error('Failed to refresh cache metadata:', err);
          }
        }
        return cachedData;
      }
      if (!response.ok) throw new Error(`API request failed: ${response.statusText}`);
      const data = await response.json();
      const etag = response.headers.get('etag');
      console.debug(`${DEBUG_PREFIX} refreshed (200)`, {
        storageKey: STORAGE_KEY,
        etag
      });
      if (typeof localStorage !== 'undefined') {
        try {
          localStorage.setItem(STORAGE_KEY, JSON.stringify({
            data,
            etag,
            timestamp: Date.now()
          }));
        } catch (err) {
          console.error('Failed to cache data:', err);
        }
      }
      return data;
    };
    fetchData().then(data => setVersionData(data)).catch(err => console.error('Failed to fetch version data:', err));
  }, []);
  const findHighestVersion = versionsMap => {
    if (!versionsMap || Object.keys(versionsMap).length === 0) return null;
    const entries = Object.entries(versionsMap);
    const active = entries.filter(([, v]) => v.upsun && v.upsun.status === 'supported' || v.upsun && v.upsun.status === 'deprecated');
    const candidates = active.length > 0 ? active : entries;
    let [highestName] = candidates[0];
    for (let i = 1; i < candidates.length; i++) {
      const [currentName] = candidates[i];
      const cp = currentName.split('.').map(Number);
      const hp = highestName.split('.').map(Number);
      for (let j = 0; j < Math.max(cp.length, hp.length); j++) {
        if ((cp[j] || 0) > (hp[j] || 0)) {
          highestName = currentName;
          break;
        } else if ((cp[j] || 0) < (hp[j] || 0)) {
          break;
        }
      }
    }
    return highestName;
  };
  const getVersion = (lang, requestedVersion = 'latest') => {
    if (lang === 'composable') {
      if (!composableData || !composableData.versions || Object.keys(composableData.versions).length === 0) return null;
      if (requestedVersion && requestedVersion !== 'latest') {
        return (requestedVersion in composableData.versions) ? requestedVersion : null;
      }
      return findHighestVersion(composableData.versions);
    }
    if (!versionData) return null;
    const imageData = versionData[lang];
    if (!imageData || !imageData.versions || Object.keys(imageData.versions).length === 0) {
      return null;
    }
    if (requestedVersion && requestedVersion !== 'latest') {
      return (requestedVersion in imageData.versions) ? requestedVersion : null;
    }
    return findHighestVersion(imageData.versions);
  };
  let code = typeof children === 'string' ? children : String(children || '');
  const codeLines = code.split('\n');
  while (codeLines.length > 0 && codeLines[0].trim() === '') codeLines.shift();
  while (codeLines.length > 0 && codeLines[codeLines.length - 1].trim() === '') codeLines.pop();
  if (codeLines.length > 0) {
    const indents = codeLines.filter(line => line.trim().length > 0).map(line => line.match(/^[ \t]*/)[0].length);
    const minIndent = Math.min(...indents);
    code = codeLines.map(line => line.slice(minIndent)).join('\n');
  }
  code = code.replace(/\{\{version:(.*?)\}\}/g, (match, params) => {
    const parts = params.split(':');
    const lang = parts[0];
    const ver = parts[1] || 'latest';
    const isComposable = lang === 'composable';
    const hasError = isComposable ? composableError : versionError;
    const dataReady = isComposable ? composableData !== null : versionData !== null;
    if (hasError) return '(unavailable)';
    if (dataReady) {
      const resolvedVersion = getVersion(lang, ver);
      return resolvedVersion || match;
    }
    return '...';
  });
  const codeBlockProps = {
    language,
    ...filename && ({
      filename
    }),
    ...icon && ({
      icon
    }),
    ...lines !== undefined && ({
      lines
    }),
    ...wrap !== undefined && ({
      wrap
    }),
    ...expandable !== undefined && ({
      expandable
    }),
    ...highlight && ({
      highlight
    }),
    ...focus && ({
      focus
    })
  };
  return <CodeBlock {...codeBlockProps}>{code}</CodeBlock>;
};

Upsun offers two Elasticsearch-based search services:

* **[Elastic Enterprise Search](#elastic-enterprise-search-current)**: current Premium service, recommended for all new projects.
* **[Elasticsearch (end of life)](#elasticsearch-end-of-life)**: versions up to 7.10, no longer maintained.

## Elastic Enterprise Search (current)

Elastic Enterprise Search is available as a Premium service. It replaces the legacy Elasticsearch service, which is no longer receiving security
updates. For full feature documentation, see the [Elastic Enterprise Search docs](https://www.elastic.co/guide/en/enterprise-search/current/index.html).

To add this service, [contact Sales](https://upsun.com/contact-us/).

### Enterprise Search supported versions

You can select the major and minor version.

Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest
available patches.

* <span class="runtime-version-badge" data-tooltip="version: 9.3.7">9.3</span>
* <span class="runtime-version-badge" data-tooltip="version: 8.19.18">8.19</span>

{/* @generated:meta MetaImageVersionList language="elasticsearch-enterprise" status="incoming" */}

### Enterprise Search deprecated versions

*No deprecated versions.*

### Enterprise Search retired versions

The following versions have been retired and are no longer available.
If your project uses a retired version, you must update to a [supported version](#enterprise-search-supported-versions) of Elastic
Enterprise search, available as a premium service.

* <span class="runtime-version-badge" data-tooltip="version: 7.17.29">7.17</span>

## Elasticsearch (end of life)

<Info>
  <h4>Replaced by Elastic Enterprise Search</h4>
  Elasticsearch changed its license in version 7.11 and is no longer open source. Instead, Upsun offers
  [Elastic Enterprise Search](#elastic-enterprise-search-current) as a premium service. [Contact Sales](https://upsun.com/contact-us/) to
  add it to your project.
</Info>

Versions up to 7.10 remain available but receive no further security updates from upstream. For full reference documentation, see the [Elasticsearch docs](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html). If you don't need the Enterprise Search feature set, [OpenSearch](/docs/add-services/opensearch) is a free, actively maintained alternative. To switch, follow the same procedure as for [upgrading](#upgrading).

### Elasticsearch supported versions

You can select the major and minor version.

Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest
available patches.

* <span class="runtime-version-badge" data-tooltip="version: 7.10.2">7.10</span>

{/* @generated:meta MetaImageVersionList language="elasticsearch" status="incoming" */}

### Elasticsearch deprecated versions

{/* @generated:meta MetaImageVersionList language="elasticsearch" status="deprecated" */}

*No deprecated versions.*

{/* @todo: show this sentence only when deprecated versions exist (requires renderImageVersionList prefix/suffix support)
To ensure your project remains stable in the future, switch to [a premium Enterprise Search version](#elastic-enterprise-search-current).
*/}

### Elasticsearch retired versions

The following versions have been retired and are no longer available.
If your project uses a retired version, you must update to a [supported version](#elasticsearch-supported-versions) of Elasticsearch or a
[supported version of Enterprise Search](#elastic-enterprise-search-current), available as a premium service.

* <span class="runtime-version-badge" data-tooltip="version: 7.9.3">7.9</span>
* <span class="runtime-version-badge" data-tooltip="version: 7.7.1">7.7</span>
* <span class="runtime-version-badge" data-tooltip="version: 7.7.1">7.6</span>
* <span class="runtime-version-badge" data-tooltip="version: 7.5.2">7.5</span>
* <span class="runtime-version-badge" data-tooltip="version: 7.2.2">7.2</span>
* <span class="runtime-version-badge" data-tooltip="version: 6.8.22">6.8</span>
* <span class="runtime-version-badge" data-tooltip="version: 6.5.4">6.5</span>

## Usage example

### 1. Configure the service

To define the service, use the `elasticsearch` type:

<DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        <SERVICE_NAME>:
          type: elasticsearch:<VERSION>
    `
  }
</DynamicCodeBlock>

For [Elastic Enterprise Search](/docs/add-services/elasticsearch#elastic-enterprise-search-current), use the `elasticsearch-enterprise` type and specify a supported version.

Changing the name of the service replaces it with a new service and all existing data is lost. Back up your data before changing the service.

### 2. Define the relationship

To define the relationship, use the following configuration:

<Tabs>
  <Tab title="Using default endpoints">
    <DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
      {`
              applications:
                # The name of the app container. Must be unique within a project.
                <APP_NAME>:
                  # Relationships enable access from this app to a given service.
                  # The example below shows simplified configuration leveraging a default service
                  # (identified from the relationship name) and a default endpoint.
                  # See the Application reference for all options for defining relationships and endpoints.
                  relationships:
                    <SERVICE_NAME>:
            `
          }
    </DynamicCodeBlock>

    You can define `SERVICE_NAME` as you like, so long as it's unique between all defined services
    and matches in both the application and services configuration.

    The example above uses [default endpoint](/docs/configure-apps/image-properties/relationships) configuration for
    relationships.
    That is, it uses default endpoints behind the scenes, providing a [relationship](/docs/configure-apps/image-properties/relationships)
    (the network address a service is accessible from) that is identical to the *name* of that service.

    Depending on your needs, instead of default endpoint configuration,
    you can use [explicit endpoint configuration](/docs/configure-apps/image-properties/relationships).

    With the above definition, the application container now has [access to the service](#use-in-app) through the relationship
    `SERVICE_NAME` and its corresponding [service environment variables](/docs/development/variables#service-environment-variables).
  </Tab>

  <Tab title="Using explicit endpoints">
    <DynamicCodeBlock language="yaml" filename="Using explicit endpoints .upsun/config.yaml">
      {`
              applications:
                # The name of the app container. Must be unique within a project.
                <APP_NAME>:
                  # Relationships enable access from this app to a given service.
                  # The example below shows configuration with an explicitly set service name and endpoint.
                  # See the Application reference for all options for defining relationships and endpoints.
                  relationships:
                    <RELATIONSHIP_NAME>:
                      service: <SERVICE_NAME>
                      endpoint: elasticsearch
            `
          }
    </DynamicCodeBlock>

    You can define `SERVICE_NAME` and `<RELATIONSHIP_NAME>` as you like, so long as it's unique between all defined
    services and relationships
    and matches in both the application and services configuration.

    The example above uses [explicit endpoint](/docs/configure-apps/image-properties/relationships) configuration for
    relationships.

    Depending on your needs, instead of explicit endpoint configuration,
    you can use [default endpoint configuration](/docs/configure-apps/image-properties/relationships).

    With the above definition, the application container now has [access to the service](#use-in-app) through the relationship
    `<RELATIONSHIP_NAME>` and its corresponding [service environment variables](/docs/development/variables#service-environment-variables).
  </Tab>
</Tabs>

### Example configuration

<Tabs>
  <Tab title="Using default endpoints">
    <DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
      {`
              applications:
                # The name of the app container. Must be unique within a project.
                myapp:
                  # Relationships enable access from this app to a given service.
                  # The example below shows simplified configuration leveraging a default service
                  # (identified from the relationship name) and a default endpoint.
                  # See the Application reference for all options for defining relationships and endpoints.
                  relationships:
                    elasticsearch:
              services:
                  # The name of the service container. Must be unique within a project.
                  elasticsearch:
                      type: elasticsearch:{{version:elasticsearch:latest}}`
          }
    </DynamicCodeBlock>

    For [Elastic Enterprise Search](/docs/add-services/elasticsearch#elastic-enterprise-search-current), use the `elasticsearch-enterprise` type and specify a supported version.
  </Tab>

  <Tab title="Using explicit endpoints">
    <DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
      {`
              applications:
                # The name of the app container. Must be unique within a project.
                myapp:
                  # Relationships enable access from this app to a given service.
                  # The example below shows configuration with an explicitly set service name and endpoint.
                  # See the Application reference for all options for defining relationships and endpoints.
                  relationships:
                    elasticsearch:
                      service: elasticsearch
                      endpoint: elasticsearch
              services:
                # The name of the service container. Must be unique within a project.
                elasticsearch:
                  type: elasticsearch:{{version:elasticsearch:latest}}`
          }
    </DynamicCodeBlock>

    For [Elastic Enterprise Search](/docs/add-services/elasticsearch#elastic-enterprise-search-current), use the `elasticsearch-enterprise` type and specify a supported version.
  </Tab>
</Tabs>

### Use in app

To use the configured service in your app, add a configuration file similar to the following to your project.

Configuration for [Elastic Enterprise Search](#elastic-enterprise-search-current) can differ. Specify `elasticsearch-enterprise` as the service type.

<Tabs>
  <Tab title="Using default endpoints">
    <DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
      {`
              applications:
                # The name of the app container. Must be unique within a project.
                myapp:
                  # The location of the application's code.
                  source:
                    root: "/"
                  # Relationships enable access from this app to a given service.
                  # The example below shows simplified configuration leveraging a default service
                  # (identified from the relationship name) and a default endpoint.
                  # See the Application reference for all options for defining relationships and endpoints.
                  relationships:
                    elasticsearch:
              services:
                elasticsearch:
                  type: elasticsearch:{{version:elasticsearch:latest}}
            `
          }
    </DynamicCodeBlock>
  </Tab>

  <Tab title="Using explicit endpoints">
    <DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
      {`
              applications:
                # The name of the app container. Must be unique within a project.
                myapp:
                  # The location of the application's code.
                  source:
                    root: "/"
                  # Relationships enable access from this app to a given service.
                  # The example below shows configuration with an explicitly set service name and endpoint.
                  # See the Application reference for all options for defining relationships and endpoints.
                  relationships:
                    elasticsearch:
                      service: elasticsearch
                      endpoint: elasticsearch
              services:
                elasticsearch:
                  type: elasticsearch:{{version:elasticsearch:latest}}`
          }
    </DynamicCodeBlock>
  </Tab>
</Tabs>

This configuration defines a single application (`myapp`).
`myapp` has access to the `elasticsearch` service through the corresponding [service environment variables](/docs/development/variables#service-environment-variables)
(as per [default endpoint](/docs/configure-apps/image-properties/relationships) configuration for relationships).

From this, `myapp` can retrieve access credentials to the service through the [relationship environment variable](/docs/add-services/elasticsearch#relationship-reference).

```bash myapp/.environment theme={null}
# Set environment variables for individual credentials.
# See: /docs/development/variables#service-environment-variables
export ELASTIC_SCHEME="${ELASTICSEARCH_SCHEME}"
export ELASTIC_HOST="${ELASTICSEARCH_HOST}"
export ELASTIC_PORT="${ELASTICSEARCH_PORT}"

# Surface more common Elasticsearch connection string variables for use in app.
export ELASTIC_USERNAME="${ELASTICSEARCH_USERNAME}"
export ELASTIC_PASSWORD="${ELASTICSEARCH_PASSWORD}"
export ELASTIC_HOSTS=["$ELASTIC_SCHEME://$ELASTIC_HOST:$ELASTIC_PORT"]
```

The `.environment` file in the `myapp` directory is automatically sourced by Upsun into the runtime environment, making `ELASTIC_HOSTS` available to connect to the service.

`ELASTIC_HOSTS`, and all [Upsun-service environment variables](/docs/development/variables#service-environment-variables) like `ELASTICSEARCH_HOST`,
are environment-dependent.
Unlike the build produced for a given commit,
they can’t be reused across environments and only allow your app to connect to a single service instance on a single environment.

A file similar to this is generated automatically for you when using the `upsun ify` command to [migrate a codebase to Upsun](/docs/get-started).

<Note>
  When you create an index on Elasticsearch,
  don't specify the `number_of_shards` or `number_of_replicas` settings in your Elasticsearch API call.
  These values are set automatically based on available resources.
</Note>

## Relationship reference

For each service [defined through a relationship](#usage-example) to your application,
Upsun automatically generates corresponding environment variables within your application container,
in the `$<RELATIONSHIP-NAME>_<SERVICE-PROPERTY>` format.

Here is example information available through the [service environment variables](/docs/development/variables#service-environment-variables) themselves,
or through the [`PLATFORM_RELATIONSHIPS` environment variable](/docs/development/variables/use-variables#use-provided-variables).

<Tabs>
  <Tab title="Service environment variables">
    You can obtain the complete list of available service environment variables in your app container by running `upsun ssh env`.

    The information about the relationship can change when an app is redeployed or restarted or the relationship is changed. Your apps should only rely on the [service environment variables](/docs/development/variables#service-environment-variables) directly rather than hard-coding any values.

    <DynamicCodeBlock language="bash">
      {`
              ELASTICSEARCH_USERNAME=
              ELASTICSEARCH_SCHEME=http
              ELASTICSEARCH_SERVICE=elasticsearch
              ELASTICSEARCH_FRAGMENT=null
              ELASTICSEARCH_IP=123.456.78.90
              ELASTICSEARCH_HOSTNAME=azertyuiopqsdfghjklm.elasticsearch.service._.eu-1.platformsh.site
              ELASTICSEARCH_PORT=9200
              ELASTICSEARCH_CLUSTER=azertyuiopqsdf-main-7rqtwti
              ELASTICSEARCH_HOST=elasticsearch.internal
              ELASTICSEARCH_REL=elasticsearch
              ELASTICSEARCH_PATH=
              ELASTICSEARCH_QUERY=[]
              ELASTICSEARCH_PASSWORD=ChangeMe
              ELASTICSEARCH_TYPE=elasticsearch:{{version:elasticsearch:latest}}
              ELASTICSEARCH_PUBLIC=false
              ELASTICSEARCH_HOST_MAPPED=false
            `
          }
    </DynamicCodeBlock>
  </Tab>

  <Tab title="`PLATFORM_RELATIONSHIPS` environment variable">
    For some advanced use cases, you can use the [`PLATFORM_RELATIONSHIPS` environment variable](/docs/development/variables/use-variables#use-provided-variables).
    The structure of the `PLATFORM_RELATIONSHIPS` environment variable can be obtained by running `upsun relationships` in your terminal:

    <DynamicCodeBlock language="json">
      {`
              {
                "username": null,
                "scheme": "http",
                "service": "elasticsearch",
                "fragment": null,
                "ip": "123.456.78.90",
                "hostname": "azertyuiopqsdfghjklm.elasticsearch.service._.eu-1.platformsh.site",
                "port": 9200,
                "cluster": "azertyuiopqsdf-main-7rqtwti",
                "host": "elasticsearch.internal",
                "rel": "elasticsearch",
                "path": null,
                "query": [],
                "password": "ChangeMe",
                "type": "elasticsearch:{{version:elasticsearch:latest}}",
                "public": false,
                "host_mapped": false
              }
            `
          }
    </DynamicCodeBlock>

    Here is an example of how to gather [`PLATFORM_RELATIONSHIPS` environment variable](/docs/development/variables/use-variables#use-provided-variables) information in a [`.environment` file](/docs/development/variables/set-variables#when-to-use-env-files):

    ```bash .environment theme={null}
    # Decode the built-in credentials object variable.
    export RELATIONSHIPS_JSON="$(echo "$PLATFORM_RELATIONSHIPS" | base64 --decode)"

    # Set environment variables for individual credentials.
    export APP_ELASTICSEARCH_HOST=="$(echo "$RELATIONSHIPS_JSON" | jq -r '.elasticsearch[0].host')"
    ```
  </Tab>
</Tabs>

For [Elastic Enterprise Search](#elastic-enterprise-search-current), use `elasticsearch-enterprise` as the service type.

## Authentication

This section applies to the [Elasticsearch (end of life)](#elasticsearch-end-of-life) service only.

By default, Elasticsearch (end of life) has no authentication.
No username or password is required to connect to it.

Starting with Elasticsearch 7.2, you can optionally enable HTTP Basic authentication.
To do so, include the following in your `.upsun/config.yaml` configuration:

<DynamicCodeBlock language="yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        elasticsearch:
            type: elasticsearch:{{version:elasticsearch:latest}}
            configuration:
              authentication:
                enabled: true`
  }
</DynamicCodeBlock>

For [Elastic Enterprise Search](#elastic-enterprise-search-current), use the `elasticsearch-enterprise` type and specify a supported version.

That enables mandatory HTTP Basic auth on all requests.
The credentials are available in any relationships that point at that service,
in the `username` and `password` properties.

You can obtain the complete list of available service environment variables in your app container by running `upsun ssh env`.

Note that the information about the relationship can change when an app is redeployed or restarted or the relationship is changed. So your apps should only rely on the [service environment variables](/docs/development/variables#service-environment-variables) directly rather than hard coding any values.

This functionality is generally not required if Elasticsearch isn't exposed on its own public HTTP route.
However, certain applications may require it, or it lets you safely expose Elasticsearch directly to the web.
To do so, add a route to `.upsun/config.yaml` that has `elasticsearch:elasticsearch` as its upstream
(where `elasticsearch` is whatever you named the service).

For example:

<DynamicCodeBlock language="yaml">
  {`
      routes:
        "https://es.{default}/":
          type: upstream
          upstream: "elasticsearch:elasticsearch"
      services:
        # The name of the service container. Must be unique within a project.
        elasticsearch:
            type: elasticsearch:{{version:elasticsearch:latest}}
            configuration:
              authentication:
                enabled: true`
  }
</DynamicCodeBlock>

## Plugins

Elasticsearch offers a number of plugins.
To enable them, list them under the `configuration.plugins` key in your `.upsun/config.yaml` file:

<DynamicCodeBlock language="yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        elasticsearch:
            type: elasticsearch:{{version:elasticsearch:latest}}
            configuration:
              plugins:
                - analysis-icu`
  }
</DynamicCodeBlock>

For [Elastic Enterprise Search](#elastic-enterprise-search-current), use the `elasticsearch-enterprise` type and specify a supported version.

In this example, the `analysis-icu` plugin is enabled.

If there is a publicly available plugin you need that isn't listed here, [contact support](/docs/core-concepts/get-support).

### Available plugins

This is the complete list of official Elasticsearch plugins that can be enabled:

| Plugin                  | Description                                                                              | 2.4 | 5.x | 6.x | 7.x | 8.x |
| ----------------------- | ---------------------------------------------------------------------------------------- | --- | --- | --- | --- | --- |
| `analysis-icu`          | Support ICU Unicode text analysis                                                        | \*  | \*  | \*  | \*  | \*  |
| `analysis-nori`         | Integrates Lucene Nori analysis module into Elasticsearch                                |     |     | \*  | \*  | \*  |
| `analysis-kuromoji`     | Japanese language support                                                                | \*  | \*  | \*  | \*  | \*  |
| `analysis-smartcn`      | Smart Chinese Analysis Plugins                                                           | \*  | \*  | \*  | \*  | \*  |
| `analysis-stempel`      | Stempel Polish Analysis Plugin                                                           | \*  | \*  | \*  | \*  | \*  |
| `analysis-phonetic`     | Phonetic analysis                                                                        | \*  | \*  | \*  | \*  | \*  |
| `analysis-ukrainian`    | Ukrainian language support                                                               |     | \*  | \*  | \*  | \*  |
| `cloud-aws`             | AWS Cloud plugin, allows storing indices on AWS S3                                       | \*  |     |     |     |     |
| `delete-by-query`       | Support for deleting documents matching a given query                                    | \*  |     |     |     |     |
| `discovery-multicast`   | Ability to form a cluster using TCP/IP multicast messages                                | \*  |     |     |     |     |
| `ingest-attachment`     | Extract file attachments in common formats (such as PPT, XLS, and PDF)                   |     | \*  | \*  | \*  | \*  |
| `ingest-user-agent`     | Extracts details from the user agent string a browser sends with its web requests        |     | \*  | \*  |     |     |
| `lang-javascript`       | JavaScript language plugin, allows the use of JavaScript in Elasticsearch scripts        |     | \*  |     |     |     |
| `lang-python`           | Python language plugin, allows the use of Python in Elasticsearch scripts                | \*  | \*  |     |     |     |
| `mapper-annotated-text` | Adds support for text fields with markup used to inject annotation tokens into the index |     |     | \*  | \*  | \*  |
| `mapper-attachments`    | Mapper attachments plugin for indexing common file types                                 | \*  | \*  |     |     |     |
| `mapper-murmur3`        | Murmur3 mapper plugin for computing hashes at index-time                                 | \*  | \*  | \*  | \*  | \*  |
| `mapper-size`           | Size mapper plugin, enables the `_size` meta field                                       | \*  | \*  | \*  | \*  | \*  |
| `transport-nio`         | Support for NIO transport                                                                |     |     |     | \*  | \*  |

### Plugin removal

Removing plugins previously added in your `.upsun/config.yaml` file doesn't automatically uninstall them from your Elasticsearch instances.
This is deliberate, as removing a plugin can result in data loss or corruption of existing data that relied on that plugin.
Removing a plugin usually requires reindexing.

To permanently remove a previously enabled plugin,
[upgrade the service](#upgrading) to create a new instance of Elasticsearch and migrate to it.
In most cases this isn't necessary, as an unused plugin has no appreciable impact on the server.

## Upgrading

The Elasticsearch data format sometimes changes between versions in incompatible ways.
Elasticsearch doesn't include a data upgrade mechanism as it's expected that all indexes can be regenerated from stable data if needed.
To upgrade (or downgrade) Elasticsearch, use a new service from scratch.

There are two approaches.

### Destructive upgrade

In your `.upsun/config.yaml` file, change the version *and* name of your Elasticsearch service.
Also update the reference to the renamed service in the application's `relationship` block.

When you push the change to Upsun, the old service is deleted and a new one with the new name is created with no data.
You can then have your application reindex data as appropriate.

This approach has the downsides of temporarily having an empty Elasticsearch instance,
which your application might or might not handle gracefully, and needing to rebuild your index afterward.
Depending on the size of your data that could take a while.

### Transitional upgrade

With a transitional approach, you temporarily have two Elasticsearch services.
Add a second Elasticsearch service with the new version, a new name, and give it a new relationship in `.upsun/config.yaml`.
You can optionally run in that configuration for a while to allow your application to populate indexes in the new service as well.

Once you're ready to switch over, remove the old Elasticsearch service and relationship.
You can optionally give the new Elasticsearch service the old relationship name if that's easier for your app to handle.
Your application is now using the new Elasticsearch service.

This approach has the benefit of never being without a working Elasticsearch instance.
On the downside, it requires two running Elasticsearch servers temporarily,
each of which consumes resources and needs adequate disk space.
Depending on the size of your data, this can require significant space.

## Exporting data

Elasticsearch data is stored in on-disk indexes. The recommended way to export it is
using the [Snapshot and Restore API](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html)
over an SSH tunnel.

1. Open an SSH tunnel to your Elasticsearch service:

```bash Terminal theme={null}
upsun tunnel:single --relationship <RELATIONSHIP_NAME>
```

2. Register a snapshot repository (a local filesystem path accessible inside the service):

```bash Terminal theme={null}
curl -X PUT "http://127.0.0.1:9200/_snapshot/my_backup" \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "fs",
    "settings": {
      "location": "/tmp/es-snapshots"
    }
  }'
```

3. Trigger a snapshot:

```bash Terminal theme={null}
curl -X PUT "http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true"
```

4. Retrieve the snapshot files from the service container using the CLI:

```bash Terminal theme={null}
upsun ssh -- tar -czf /tmp/es-snapshot.tar.gz /tmp/es-snapshots
upsun scp remote:/tmp/es-snapshot.tar.gz ./es-snapshot.tar.gz
```

Alternatively, you can re-index all your data from the primary data source
(for example your application database) instead of using snapshots.

If authentication is enabled on your Elasticsearch service, add the `-u user:password` flag to the `curl` commands.
