> ## 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.

# Solr (Search service)

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>;
};

export const SolrModulesTable = () => {
  const [DATA] = useState(() => JSON.parse("{\"versions\":[\"10.0\",\"9.9\"],\"extensions\":{\"analysis-extras\":{\"description\":\"Extra analyzers and token filters for advanced text analysis use cases.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"analytics\":{\"description\":\"Streaming expressions and advanced analytics functions.\",\"versions\":{\"9.9\":\"available\"}},\"clustering\":{\"description\":\"Result clustering capabilities for grouped search output.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"cross-dc\":{\"description\":\"Cross-data-center replication and failover tooling.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"cuvs\":{\"description\":\"Vector search acceleration module based on cuVS.\",\"versions\":{\"10.0\":\"available\"}},\"extraction\":{\"description\":\"Tika-based extraction for PDF, Office, and other document formats.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"gcs-repository\":{\"description\":\"Repository plugin for backups and snapshots on Google Cloud Storage.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"hadoop-auth\":{\"description\":\"Hadoop-compatible authentication integrations.\",\"versions\":{\"9.9\":\"available\"}},\"hdfs\":{\"description\":\"HDFS integration for repository and storage operations.\",\"versions\":{\"9.9\":\"available\"}},\"jaegertracer-configurator\":{\"description\":\"Jaeger tracing configuration helpers.\",\"versions\":{\"9.9\":\"available\"}},\"jwt-auth\":{\"description\":\"JWT authentication support for Solr APIs.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"langid\":{\"description\":\"Automatic language identification update processor.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"language-models\":{\"description\":\"Language model resources used by NLP-oriented features.\",\"versions\":{\"10.0\":\"available\"}},\"llm\":{\"description\":\"Large language model integration components.\",\"versions\":{\"9.9\":\"available\"}},\"ltr\":{\"description\":\"Learning To Rank query reranking framework.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"opentelemetry\":{\"description\":\"OpenTelemetry instrumentation for traces and metrics.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"s3-repository\":{\"description\":\"Repository plugin for backups and snapshots on S3-compatible storage.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"scripting\":{\"description\":\"Script engine integrations for custom processing.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}},\"sql\":{\"description\":\"SQL query parser and SQL request handler support.\",\"versions\":{\"9.9\":\"available\",\"10.0\":\"available\"}}}}"));
  const [isClient, setIsClient] = useState(false);
  const [search, setSearch] = useState('');
  const [versionFilter, setVersionFilter] = useState('');
  useEffect(() => {
    setIsClient(true);
    if (typeof document !== 'undefined') document.documentElement.classList.add('meta-js');
  }, []);
  const allNames = Object.keys(DATA.extensions).sort((a, b) => a.localeCompare(b));
  if (allNames.length === 0) return <p>No Solr modules found.</p>;
  if (!isClient) return null;
  const query = search.toLowerCase().trim();
  const filtered = allNames.filter(name => {
    const ext = DATA.extensions[name];
    const matchesSearch = !query || name.toLowerCase().includes(query) || (ext.description || '').toLowerCase().includes(query);
    const matchesVersion = !versionFilter || !!ext.versions[versionFilter];
    return matchesSearch && matchesVersion;
  });
  const statusColor = status => {
    switch (status) {
      case 'available':
        return 'pg-ext-status-available';
      case 'built-in':
        return 'pg-ext-status-builtin';
      case 'default':
        return 'pg-ext-status-default';
      case 'deprecated':
        return 'pg-ext-status-deprecated';
      case 'retired':
        return 'pg-ext-status-retired';
      default:
        return 'pg-ext-status-unavailable';
    }
  };
  return <div className="pg-ext-wrapper">
      <div className="pg-ext-toolbar">
        <div className="pg-ext-search-wrapper">
          <svg className="pg-ext-search-icon" width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round">
            <circle cx="11" cy="11" r="8" />
            <line x1="21" y1="21" x2="16.65" y2="16.65" />
          </svg>
          <input type="text" className="pg-ext-search" placeholder="Search extensions..." value={search} onChange={e => setSearch(e.target.value)} onKeyDown={e => {
    if (e.key === 'Escape') setSearch('');
  }} />
          {search && <button className="pg-ext-search-clear" onClick={() => setSearch('')} aria-label="Clear search">✕</button>}
        </div>
        <select className="pg-ext-version-select" value={versionFilter} onChange={e => setVersionFilter(e.target.value)}>
          <option value="">All versions</option>
          {DATA.versions.map(v => <option key={v} value={v}>Solr {v}</option>)}
        </select>
      </div>

      <p className="pg-ext-count">
        Showing <strong>{filtered.length}</strong> of {allNames.length} extensions
      </p>

      <div className="pg-ext-table-container">
        <table className="pg-ext-table">
          <thead>
            <tr>
              <th>Extension</th>
              <th>Description</th>
              <th>Supported versions</th>
            </tr>
          </thead>
          <tbody>
            {filtered.length === 0 ? <tr>
                <td colSpan="3" className="pg-ext-empty">No extensions match your filters.</td>
              </tr> : filtered.map(extName => {
    const ext = DATA.extensions[extName];
    return <tr key={extName}>
                    <td><code>{extName}</code></td>
                    <td className="pg-ext-desc">{ext.description || ''}</td>
                    <td>
                      <div className="pg-ext-version-dots">
                        {DATA.versions.map(v => {
      const status = ext.versions[v] || '';
      return <span key={v} className={`pg-ext-dot ${statusColor(status)}`} data-tooltip={`${v}: ${status || 'not available'}`}>
                              {v}
                            </span>;
    })}
                      </div>
                    </td>
                  </tr>;
  })}
          </tbody>
        </table>
      </div>
    </div>;
};

Apache Solr is a scalable and fault-tolerant search index.

Solr search with generic schemas provided, and a custom schema is also supported. See the [Solr documentation](https://lucene.apache.org/solr/6_3_0/index.html) for more information.

## 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: 10.0.0">10.0</span>
* <span class="runtime-version-badge" data-tooltip="version: 9.9.0">9.9</span>
* <span class="runtime-version-badge" data-tooltip="version: 9.6.1">9.6</span>
* <span class="runtime-version-badge" data-tooltip="version: 9.4.0">9.4</span>
* <span class="runtime-version-badge" data-tooltip="version: 9.2.0">9.2</span>
* <span class="runtime-version-badge" data-tooltip="version: 9.1.0">9.1</span>

## Deprecated versions

The following versions are still available in your projects,
but they're at their end of life and are no longer receiving security updates from upstream.

*No deprecated versions.*

To ensure your project remains stable in the future, switch to a [supported version](#supported-versions).

## 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](#supported-versions).

* <span class="runtime-version-badge" data-tooltip="version: 9.0.0">9.0</span>
* <span class="runtime-version-badge" data-tooltip="version: 8.11.1">8.11</span>
* <span class="runtime-version-badge" data-tooltip="version: 8.0.0">8.0</span>
* <span class="runtime-version-badge" data-tooltip="version: 7.7.3">7.7</span>
* <span class="runtime-version-badge" data-tooltip="version: 7.6.0">7.6</span>
* <span class="runtime-version-badge" data-tooltip="version: 6.6.6">6.6</span>
* <span class="runtime-version-badge" data-tooltip="version: 6.3.0">6.3</span>
* <span class="runtime-version-badge" data-tooltip="version: 4.10.4">4.10</span>
* <span class="runtime-version-badge" data-tooltip="version: 3.6.2">3.6</span>

## Relationship reference

For each service [defined via 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`.

    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.

    <DynamicCodeBlock language="bash">
      {`
              SOLR_USERNAME=
              SOLR_SCHEME=solr
              SOLR_SERVICE=solr
              SOLR_IP=123.456.78.90
              SOLR_FRAGMENT=
              SOLR_HOSTNAME=azertyuiopqsdfghjklm.solr.service._.eu-1.platformsh.site
              SOLR_PORT=8080
              SOLR_CLUSTER=azertyuiopqsdf-main-afdwftq
              SOLR_HOST=solr.internal
              SOLR_REL=solr
              SOLR_PATH=solr/collection1
              SOLR_QUERY={}
              SOLR_PASSWORD=
              SOLR_EPOCH=0
              SOLR_TYPE=solr:{{version:solr:latest}}
              SOLR_PUBLIC=false
              SOLR_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#service-environment-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": "solr",
                "service": "solr",
                "fragment": null,
                "ip": "123.456.78.90",
                "hostname": "azertyuiopqsdfghjklm.solr.service._.eu-1.platformsh.site",
                "port": 8080,
                "cluster": "azertyuiopqsdf-main-afdwftq",
                "host": "solr.internal",
                "rel": "solr",
                "path": "solr\/collection1",
                "query": [],
                "password": null,
                "type": "solr:{{version:solr: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_SOLR_HOST="$(echo "$RELATIONSHIPS_JSON" | jq -r '.solr[0].host')"
    ```
  </Tab>
</Tabs>

## Usage example

### 1. Configure the service

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

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

Note that changing the name of the service replaces it with a brand 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 leverages [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 (`APP_NAME`) now has access to the service via 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: solr
            `
          }
    </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 leverages [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) via 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:
                    solr:  
              services:
                # The name of the service container. Must be unique within a project.
                solr:
                  type: solr:{{version:solr: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:
                  # 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:
                    solr:
                      service: solr
                      endpoint: solr    
              services:
                # The name of the service container. Must be unique within a project.
                solr:
                  type: solr:{{version:solr:latest}}`
          }
    </DynamicCodeBlock>
  </Tab>
</Tabs>

### Use in app

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

<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: "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:
                    solr:    
              services:
                # The name of the service container. Must be unique within a project.
                solr:
                  type: solr:{{version:solr: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: "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:
                    solr:
                      service: solr
                      endpoint: solr    
              services:
                # The name of the service container. Must be unique within a project.
                solr:
                  type: solr:{{version:solr:latest}}`
          }
    </DynamicCodeBlock>
  </Tab>
</Tabs>

This configuration defines a single application (`myapp`), whose source code exists in the `<PROJECT_ROOT>/myapp` directory.<br />
`myapp` has access to the `solr` service, via a relationship whose name is [identical to the service name](#2-define-the-relationship)
(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 variables](#relationship-reference).

```bash myapp/.environment theme={null}
# Set environment variables for individual credentials.
# For more information, please visit /docs/development/variables#service-environment-variables.
export QUEUE_SCHEME="${SOLR_SCHEME}"
export QUEUE_USERNAME="${SOLR_USERNAME}"
export QUEUE_PASSWORD="${SOLR_PASSWORD}"
export QUEUE_HOST="${SOLR_HOST}"
export QUEUE_PORT="${SOLR_PORT}"

# Set a single RabbitMQ connection string variable for AMQP.
export AMQP_URL="${QUEUE_SCHEME}://${QUEUE_USERNAME}:${QUEUE_PASSWORD}@${QUEUE_HOST}:${QUEUE_PORT}/"
```

The above file — `.environment` in the `myapp` directory — is automatically sourced by Upsun into the runtime environment, so that the variable `SEARCH_URL` can be used within the application to connect to the service.

Note that `SEARCH_URL`, and all Upsun [service environment variables](/docs/development/variables#service-environment-variables) like `SOLR_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 very similar to this is generated automatically for your when using the `upsun ify` command to [migrate a codebase to Upsun](/docs/get-started).

## Solr 4

For Solr 4, Upsun supports only a single core per server called `collection1`.

You must provide your own Solr configuration via a `core_config` key in your `.upsun/config.yaml`:

<DynamicCodeBlock language="yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        solr:
          type: "solr:4.10"
          configuration:
            core_config: !archive "<DIRECTORY>"`
  }
</DynamicCodeBlock>

`<DIRECTORY>` points to a directory in the Git repository, in or below the `.upsun/` folder. This directory needs to contain everything that Solr needs to start a core. At the minimum, `solrconfig.xml` and `schema.xml`.

For example, place them in `.upsun/solr/conf/` such that the `schema.xml` file is located at `.upsun/solr/conf/schema.xml`. You can then reference that path like this -

```yaml .upsun/config.yaml theme={null}
services:
  # The name of the service container. Must be unique within a project.
  solr:
    type: "solr:4.10"
    configuration:
      core_config: !archive "solr/conf/"
```

## Solr 6 and later

For Solr 6 and later Upsun supports multiple cores via different endpoints. Cores and endpoints are defined separately, with endpoints referencing cores. Each core may have its own configuration or share a configuration. It is best illustrated with an example.

<DynamicCodeBlock language="yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        solr:
          type: solr:{{version:solr:latest}}
          configuration:
            cores:
              mainindex:
                conf_dir: !archive "core1-conf"
              extraindex:
                conf_dir: !archive "core2-conf"
            endpoints:
              main:
                core: mainindex
              extra:
                core: extraindex`
  }
</DynamicCodeBlock>

The above definition defines a single Solr 10.0 server. That server has 2 cores defined:

* `mainindex` — the configuration for which is in the `.upsun/core1-conf` directory
* `extraindex` — the configuration for which is in the `.upsun/core2-conf` directory.

It then defines two endpoints: `main` is connected to the `mainindex` core while `extra` is connected to the `extraindex` core. Two endpoints may be connected to the same core but at this time there would be no reason to do so. Additional options may be defined in the future.

Each endpoint is then available in the relationships definition in `.upsun/config.yaml`. For example, to allow an application to talk to both of the cores defined above its configuration should contain the following:

<DynamicCodeBlock language="yaml" filename=".upsun/config.yaml">
  {`
      applications:
        # The name of the app container. Must be unique within a project.
        myapp:

          type: "php:{{version:php:latest}}"

          source:
            root: "myapp"

          [...]

          # Relationships enable access from this app to a given service.
          # The example below shows configuration with explicitly set service names and endpoints.
          # See the Application reference for all options for defining relationships and endpoints.
          relationships:
            solrsearch1:
              service: solr
              endpoint: main
            solrsearch2:
              service: solr
              endpoint: extra

      services:
        # The name of the service container. Must be unique within a project.
        solr:
          type: solr:{{version:solr:latest}}
          configuration:
            cores:
              mainindex:
                conf_dir: !archive "core1-conf"
              extraindex:
                conf_dir: !archive "core2-conf"
            endpoints:
              main:
                core: mainindex
              extra:
                core: extraindex`
  }
</DynamicCodeBlock>

That is, the application's environment would include a `solrsearch1` relationship that connects to the `main` endpoint, which is the `mainindex` core, and a `solrsearch2` relationship that connects to the `extra` endpoint, which is the `extraindex` core.

The relationships array would then look something like the following:

```json theme={null}
{
  "solrsearch1": [
    {
      "path": "solr/mainindex",
      "host": "248.0.65.197",
      "scheme": "solr",
      "port": 8080
    }
  ],
  "solrsearch2": [
    {
      "path": "solr/extraindex",
      "host": "248.0.65.197",
      "scheme": "solr",
      "port": 8080
    }
  ]
}
```

### Configsets

For even more customizability, it's also possible to define Solr configsets. For example, the following snippet would define one configset, which would be used by all cores. Specific details can then be overridden by individual cores using `core_properties`, which is equivalent to the Solr `core.properties` file.

<DynamicCodeBlock language="yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        solr:
          type: solr:{{version:solr:latest}}
          configuration:
            configsets:
              mainconfig: !archive "configsets/solr8"
            cores:
              english_index:
                core_properties: |
                  configSet=mainconfig
                  schema=english/schema.xml
              arabic_index:
                core_properties: |
                  configSet=mainconfig
                  schema=arabic/schema.xml
            endpoints:
              english:
                core: english_index
              arabic:
                core: arabic_index`
  }
</DynamicCodeBlock>

In this example, `.upsun/configsets/solr8` contains the configuration definition for multiple cores. There are then two cores created:

* `english_index` uses the defined configset, but specifically the `.upsun/configsets/solr8/english/schema.xml` file
* `arabic_index` is identical except for using the `.upsun/configsets/solr8/arabic/schema.xml` file.

Each of those cores is then exposed as its own endpoint.

Note that not all core properties features make sense to specify in the `core_properties`. Some keys, such as `name` and `dataDir`, aren't supported, and may result in a `solrconfig` that fails to work as intended, or at all.

### Default configuration

#### Default for version 9+

If you don't specify any configuration, the following default is used:

<DynamicCodeBlock language="yaml">
  {`
      services:
        # The name of the service container. Must be unique within a project.
        solr:
          type: solr:{{version:solr:latest}}
          configuration:
            cores:
              collection1:
                conf_dir: !archive "example"
            endpoints:
              solr:
                core: collection1`
  }
</DynamicCodeBlock>

The example configuration directory is equivalent to the [Solr example configuration set](https://github.com/apache/solr/tree/main/solr/server/solr/configsets/sample_techproducts_configs/conf).
This default configuration is designed only for testing.
You are strongly recommended to define your own configuration with a custom core and endpoint.

#### Default for versions below 9

If you don't specify any configuration, the following default is used:

```yaml .upsun/config.yaml theme={null}
services:
  # The name of the service container. Must be unique within a project.
  solr:
    type: solr:8.4
    configuration:
      cores:
        collection1: {}
      endpoints:
        solr:
          core: collection1
```

The default configuration is based on an older version of the Drupal 8 Search API Solr module that is no longer in use.
You are strongly recommended to define your own configuration with a custom core and endpoint.

### Limitations

The recommended maximum size for configuration directories (zipped) is 2MB. These need to be monitored to ensure they don't grow beyond that. If the zipped configuration directories grow beyond this, performance declines and deploys become longer. The directory archives are compressed and string encoded. You could use this bash pipeline

```bash theme={null}
echo $(($(tar czf - . | base64 | wc -c )/(1024*1024))) Megabytes
```

inside the directory to get an idea of the archive size.

The configuration directory is a collection of configuration data, like a data dictionary, e.g. small collections of key/value sets. The best way to keep the size small is to restrict the directory context to plain configurations. Including binary data like plugin `.jar` files inflates the archive size, and isn't recommended.

## Accessing the Solr server administrative interface

Because Solr uses HTTP for both its API and admin interface it's possible to access the admin interface over an SSH tunnel.

<DynamicCodeBlock language="bash" filename="Access Solr admin interface">
  {`
      upsun tunnel:single --relationship <RELATIONSHIP_NAME>
    `}
</DynamicCodeBlock>

By default, this opens a tunnel at `127.0.0.1:30000`.

You can now open `http://localhost:30000/solr/` in a browser to access the Solr admin interface.
Note that you can't create indexes or users this way,
but you can browse the existing indexes and manipulate the stored data.

## Available plugins

This is the complete list of plugins that are available and loaded by default:

| Plugin                                                                             | Description                                            | 8.11 | 9.x |
| ---------------------------------------------------------------------------------- | ------------------------------------------------------ | ---- | --- |
| [JTS](https://solr.apache.org/guide/8_1/spatial-search.html#jts-and-polygons-flat) | Library for creating and manipulating vector geometry. | \*   | \*  |
| [ICU4J](https://solr.apache.org/guide/8_3/language-analysis.html)                  | Library providing Unicode and globalization support.   | \*   | \*  |

## Available modules

The following is the complete list of supported Solr modules.

### Modules vs plugins

In Solr, a **module** is a packaged feature set that can be added to the classpath.
A **plugin** is a specific Solr component (for example a request handler, parser, or repository implementation) that may rely on a module.

In practice, you often enable modules first, then use plugins provided by those modules in your configset.

### When to enable modules

Enable modules only when your configset needs them:

* `extraction`: Tika-based document extraction
* `langid`: language detection
* `ltr`: learning-to-rank components
* `clustering`: result clustering features
* `sql`: SQL query endpoint support
* `analysis-extras`: additional analysis filters and tokenizers

Loading only the modules you need reduces startup overhead and avoids unnecessary classpath bloat.

### Example: enable modules in the service configuration

Use the `configuration.modules` key in your service definition:

```yaml .upsun/config.yaml theme={null}
services:
  solr:
    type: solr:9.9
    configuration:
      modules:
        - analysis-extras
        - langid
        - ltr
```

### Bundled modules (Solr 9.9+)

Solr 9.8 made [`<lib>` directives in `solrconfig.xml` opt-in](https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-9.html#solr-9-8), and Solr 10.0 ([SOLR-16781](https://issues.apache.org/jira/browse/SOLR-16781)) removed support for them entirely.
As a result, bundled modules shipped under `/opt/solr/<VERSION>/modules/` are no longer auto-loaded from `<lib>` references in your configset.
Instead, list the modules you need in `configuration.modules`.

By default, no bundled modules are loaded. Only the modules you explicitly request are added to the classpath.

If you're upgrading from Solr 9.6 or earlier and your configset relies on `<lib>` directives,
add the matching modules to `configuration.modules` when you upgrade:

```yaml .upsun/config.yaml theme={null}
services:
  solr:
    type: solr:9.9
    configuration:
      modules:
        - extraction
        - analysis-extras
        - langid
        - ltr
```

The `configuration.modules` field is supported only on Solr 9.9 and later.
On Solr 9.6 and earlier, modules continue to load from `<lib>` directives in your configset.

### Typical migration issues (9.9+)

If you upgraded from an older setup that used `<lib>` directives, add the matching modules in `configuration.modules`.

| Symptom                                               | Likely missing module |
| ----------------------------------------------------- | --------------------- |
| ClassNotFound errors related to Tika extraction       | `extraction`          |
| Language detection handlers/fields fail to initialize | `langid`              |
| LTR parser/components fail to load                    | `ltr`                 |
| SQL endpoint/features unavailable                     | `sql`                 |

### Validation checklist after enabling modules

After deployment, verify the following:

* Solr service starts successfully
* Core loading completes without classpath errors
* The feature tied to the module works (query/index/update path)
* Service logs contain no module-related `ClassNotFound`/initialization errors

### Supported modules matrix

<div className="meta-static-fallback">
  <div className="pg-ext-wrapper"><div className="pg-ext-table-container"><table className="pg-ext-table"><thead><tr><th>Extension</th><th>Description</th><th>Supported versions</th></tr></thead><tbody><tr><td><code>analysis-extras</code></td><td className="pg-ext-desc">Extra analyzers and token filters for advanced text analysis use cases.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>analytics</code></td><td className="pg-ext-desc">Streaming expressions and advanced analytics functions.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="10.0: not available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>clustering</code></td><td className="pg-ext-desc">Result clustering capabilities for grouped search output.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>cross-dc</code></td><td className="pg-ext-desc">Cross-data-center replication and failover tooling.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>cuvs</code></td><td className="pg-ext-desc">Vector search acceleration module based on cuVS.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="9.9: not available">9.9</span></div></td></tr><tr><td><code>extraction</code></td><td className="pg-ext-desc">Tika-based extraction for PDF, Office, and other document formats.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>gcs-repository</code></td><td className="pg-ext-desc">Repository plugin for backups and snapshots on Google Cloud Storage.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>hadoop-auth</code></td><td className="pg-ext-desc">Hadoop-compatible authentication integrations.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="10.0: not available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>hdfs</code></td><td className="pg-ext-desc">HDFS integration for repository and storage operations.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="10.0: not available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>jaegertracer-configurator</code></td><td className="pg-ext-desc">Jaeger tracing configuration helpers.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="10.0: not available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>jwt-auth</code></td><td className="pg-ext-desc">JWT authentication support for Solr APIs.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>langid</code></td><td className="pg-ext-desc">Automatic language identification update processor.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>language-models</code></td><td className="pg-ext-desc">Language model resources used by NLP-oriented features.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="9.9: not available">9.9</span></div></td></tr><tr><td><code>llm</code></td><td className="pg-ext-desc">Large language model integration components.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-unavailable" data-tooltip="10.0: not available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>ltr</code></td><td className="pg-ext-desc">Learning To Rank query reranking framework.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>opentelemetry</code></td><td className="pg-ext-desc">OpenTelemetry instrumentation for traces and metrics.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>s3-repository</code></td><td className="pg-ext-desc">Repository plugin for backups and snapshots on S3-compatible storage.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>scripting</code></td><td className="pg-ext-desc">Script engine integrations for custom processing.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr><tr><td><code>sql</code></td><td className="pg-ext-desc">SQL query parser and SQL request handler support.</td><td><div className="pg-ext-version-dots"><span className="pg-ext-dot pg-ext-status-available" data-tooltip="10.0: available">10.0</span><span className="pg-ext-dot pg-ext-status-available" data-tooltip="9.9: available">9.9</span></div></td></tr></tbody></table></div></div>
</div>

<SolrModulesTable />

## Upgrading

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

There are two approaches.

### Destructive upgrade

In your `.upsun/config.yaml` file, change the version of your Solr service *and* its name.
Be sure to also update the reference to the now changed service name in it's corresponding application's `relationship` block.

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

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

### Transitional upgrade

For a transitional approach you temporarily have two Solr services. Add a second Solr 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 cut over, remove the old Solr service and relationship. You may optionally have the new Solr service use the old relationship name if that's easier for your application to handle. Your application is now using the new Solr service.

This approach has the benefit of never being without a working Solr instance. On the downside, it requires two running Solr servers temporarily, each of which consumes resources and need adequate disk space. Depending on the size of your data that may be a lot of disk space.