- Managed cloud - Elastic Cloud (Elastic, Inc.’s SaaS) or AWS OpenSearch Service (AWS’s managed OpenSearch). Both are managed by their respective vendors; you supply only the endpoint + credentials.
- Lucenia - self-hosted with a paid commercial license. Founded by the original OpenSearch creator at AWS, Lucenia is 100% wire-compatible with the Elasticsearch / OpenSearch API and adds multimodal search (vector + geospatial + numerics + timestamps + IP). Tensor9 has a direct partnership with Lucenia.
- Self-hosted OSS - OpenSearch or Elasticsearch OSS that the customer runs themselves on Kubernetes or VMs / bare metal.
What the customer provides
| Field | Purpose |
|---|---|
| Cluster URL | The https://host:port endpoint of the coordinating nodes. |
| Username + password (or API key) | The credential the appliance authenticates with. Elastic Cloud + Lucenia + OpenSearch all support API keys; basic auth works for legacy clients. |
| CA certificate (optional) | The trust anchor for the cluster’s TLS certificate when the customer uses a private CA. |
| Index prefix (optional) | A namespace prefix so the appliance’s indices do not collide with other tenants on the same cluster. |
What changes in the deployment stack
When customer-provided Elasticsearch is selected, the compiler:- Drops the default-shipped OpenSearch cluster from the deployment stack (no managed-service resource, no in-cluster StatefulSet, no automated snapshot repository).
- Wires the appliance’s services to the customer’s cluster URL.
- Injects the customer’s credentials as secrets the services read at startup.
- Sets the index prefix the appliance writes under.
Why Lucenia?
Lucenia is highlighted on this page as the recommended commercial alternative for customers who want the search-API contract on their own infrastructure, without Elastic licensing concerns. It is source-available Apache code with a paid commercial license. Key properties:- Wire-compatible with the Elasticsearch / OpenSearch API. Your existing clients work unchanged.
- Multimodal search built in: vector, geospatial, numerics, timestamps, and IP, all queryable in a single index.
- Founded by the original OpenSearch creator (Nick Knize), the engineer who led OpenSearch at AWS for four years.
- Tensor9 partnership - Tensor9 consolidates Lucenia’s prior multi-mechanism deployment story into a single origin stack. See the case study.
What the customer takes on
When your customer brings their own search cluster, they own:- Cluster provisioning, node sizing, and shard count planning.
- Snapshot configuration and snapshot repository (S3, GCS, Azure Blob, or shared filesystem).
- Patching, version upgrades, and major-version migrations.
- High-availability replica configuration and rolling restarts.
- Monitoring and alerting on the cluster (heap pressure, GC pauses, indexing rate, search latency).
What stays your responsibility
- All application-level concerns: index mappings, analyzer configuration, query design, relevance tuning, vector embedding generation.
- Your services continue to be observable through Tensor9’s normal mechanisms.
- Operations commands that operate on the appliance’s services still work normally. Operations commands cannot reach into your customer’s search cluster.
Authentication and rotation
The username and password (or API key) are stored as Customer-Supplied Secrets - Tensor9 has no visibility into the underlying value. The appliance reads them at startup and on every reconnection. Two rotation paths:- Username + password: rotate the password in the customer’s cluster (Elastic Cloud / Lucenia / OpenSearch admin UI) and update the secret in the customer’s secret store; restart the affected services.
- API key: API keys are independently revocable in all three families. Mint a new API key, update the secret, restart - then revoke the old one once the rollout settles.