Aten Design Group: Search Across Multiple Drupal Sites with Pantheon SOLR

At Aten, this challenge comes up regularly with clients running multi-site Drupal architectures on Pantheon. The solution we’ve landed on keeps everything within the platform, using four contributed modules working together as a hub-and-spoke proxy. This post walks through the architecture, why it exists, and how to implement it.Four contributed modules make this work:

Hub: pantheon_solr_api

SELECT queries bypass Drupal’s bootstrap entirely. On a warm server, the round trip through the proxy adds approximately 5ms of overhead. Writes, admin actions, and schema operations go through the Drupal controller instead, which adds around 150ms. That’s acceptable for infrequent operations.Because client sites never manage the Solr schema directly, skip_schema_check is permanently enabled. The connector also auto-detects the Solr version by querying the hub’s admin/system endpoint, falling back to 8.11.4 (Pantheon’s current managed version) if the endpoint is unreachable.Then run the registration command:

Client: search_api_solr_proxy + search_api_solr_proxy_pantheon_connector

Client registrations are tracked in Drupal config, keyed by the combination of each site’s Search API site hash and index ID, the same namespace Search API Solr uses internally to scope documents.Here is the path of a typical user search on a client site:

1. Auth injection: every outbound request gets an X-Pantheon-Solr-Key header carrying the API key from the Key module entity.
2. URL rewriting: SELECT queries are redirected to /pantheon-solr-proxy.php on the hub; everything else routes to /solr-proxy/{action} through Drupal.

From Pantheon’s perspective, only the hub ever touches Solr. The constraint is satisfied. From Search API’s perspective, every client is talking to a Solr instance in the normal way. The architecture sits between those two layers.

How a Search Query Actually Travels

drush pantheon-solr-proxy:register

Every request is validated against a shared API key before it reaches Solr. The key is read from a configured Key module entity (backed by a Pantheon Secret) and compared using hash_equals(), a timing-safe comparison that prevents key enumeration attacks. Only a hardcoded allowlist of Solr actions (select, update, update/json, admin/ping, admin/luke, config, and a handful of others) will be forwarded. Anything outside that list returns a 403.

Getting It Set Up

On the hub site

If you’re building a multi-site Drupal ecosystem and working through the hard architectural questions around search, shared data, and cross-site workflows, get in touch with the Aten team. This is the kind of problem we solve.The hub-and-spoke proxy described here is that response. It works within the platform’s model, keeps credentials out of the codebase, and adds minimal latency to the critical read path.

On each client site

Search feels like a solved problem. Until you’re managing a network of Drupal sites and your users expect to find content regardless of which one it lives on, that is. At that point, the question stops being “how do we add search?” and starts being “how do we build a unified search experience across an entire digital ecosystem?”The solution is a hub-and-spoke proxy. One Drupal site (the hub) owns the Solr core and exposes it to other sites over authenticated HTTP. Every other site (the clients) routes its search queries through the hub instead of connecting to Solr directly.This is a reasonable security tradeoff for single-site use. But for a multi-site architecture where you need a single search index spanning many sites, it forces you to think architecturally rather than just reach for a configuration option.Pantheon’s managed Solr is excellent: zero server administration, mTLS-secured connections, schema management handled through a purpose-built API. But it comes with a hard platform constraint: each Drupal site environment gets exactly one Solr core, and that core is network-isolated to that environment.search_api_solr_proxy is a framework-only module. It provides the abstract SolrProxyConnectorBase class but is not useful on its own. search_api_solr_proxy_pantheon_connector is the Pantheon-specific implementation.

A Few Things Worth Knowing

Unified search across a multi-site Drupal architecture is one of those problems that looks straightforward until you try to implement it on a managed platform. Pantheon’s security model solves a lot of problems, but it introduces constraints that require a deliberate architectural response.For transport, it swaps in a custom cURL adapter that uses the mTLS certificate Pantheon provisions at ~/certs/binding.pem. Schema uploads and core reloads go through Pantheon’s proprietary endpoints rather than the standard Solr APIs.On each client site, the connector replaces the standard Search API server configuration (host, port, path, core) with a single hub_url field. A Guzzle middleware stack handles two things:

Building Across Site Boundaries

Copy pantheon-solr-proxy.php (provided by pantheon_solr_api) to your hub site’s web root. This is the fast-path script for SELECT queries.There is no platform mechanism to point a second Drupal site at another site’s Solr instance. Each site can only talk to its own.Document namespacing is automatic. Search API Solr already scopes every indexed document with a per-site hash and index ID prefix. Each client site’s documents live in separate namespaces within the same Solr core. Cross-site queries need to either search all namespaces or be scoped deliberately; your Views or custom query code controls this.