Logo VitNode
Documentation

Elasticsearch

Replace VitNode's default Postgres search provider with Elasticsearch or OpenSearch and rebuild your index safely.

Use Elasticsearch when your site-wide search needs fuzzy matching, custom ranking, or a search cluster separate from Postgres. VitNode keeps Postgres as the canonical index; this adapter mirrors it, so switching is pleasantly boring.

Install the adapter

Run this in the app or API workspace that owns vitnode.api.config.ts.

Install Elasticsearch support
bun add @vitnode/elasticsearch@canary

Add the cluster URL and adapter

Set ELASTICSEARCH_NODE to your Elasticsearch or OpenSearch endpoint, then register the adapter in the API config.

.env
ELASTICSEARCH_NODE=http://localhost:9200
apps/api/src/vitnode.api.config.ts
import { ElasticsearchSearchAdapter } from '@vitnode/elasticsearch'

export const vitNodeApiConfig = buildApiConfig({
  search: {
    adapter: ElasticsearchSearchAdapter({
      node: process.env.ELASTICSEARCH_NODE,
      index: 'vitnode',
    }),
  },
  plugins: [blogApiPlugin()],
})

For Elastic Cloud, use cloudId and apiKey instead of node. The adapter also accepts username and password for a self-hosted secured cluster.

Rebuild the mirror

Restart the API, then open Core → Advanced → Search in the AdminCP and run Rebuild index. New changes are mirrored automatically; the rebuild fills the historical records already in Postgres. Rebuilding (and clearing a collection) needs the Rebuild and clear the search index permission (system:can_manage_search) - viewing the page alone is not enough.

Upgrading an existing index

Documents now carry authorIds (a list) instead of authorId, plus drafts as private documents. If your index was created before that, delete it in Elasticsearch and run Rebuild index. VitNode recreates it with the new mapping.

Indexes created before uuid and bigint ids

Documents now carry an itemKey keyword with the record id as text, so uuid and bigint records can be found. VitNode adds the field to an existing index the first time it uses it. Older documents get a value on the next Rebuild index; until then, results fall back to the numeric itemId, which works for serial ids only.

Keep Postgres

Do not delete core_search_index. It remains VitNode's source of truth and lets you switch providers without losing your map back home.

Next