Elasticsearch Lab

A standalone Elasticsearch 9.5.2 node with Kibana 9.5.2, running on the dev VM since 2026-08-27. It exists so people can experiment with real Elasticsearch without touching the platform’s search engine.

Caution

This is a sandbox, not platform infrastructure. No Logrite service reads from or writes to it. It has no backups, no monitoring and no HA, and it may be wiped without notice. It is dev-only — there is no prod counterpart. Never put customer or production data in it.

Why it is separate from OpenSearch

Logrite runs OpenSearch 3.3.1, which forked from Elasticsearch in 2021 and has diverged substantially since. Experiments run against OpenSearch cannot answer questions about Elasticsearch, because several things simply do not exist there:

	Elasticsearch 9.5	OpenSearch 3.3
Query language	ES|QL (piped: FROM idx | STATS ... BY ...)	PPL — different syntax and semantics
Semantic fields	semantic_text, built-in inference endpoints	ML-commons plugin, different API
Client libraries	elasticsearch / @elastic/elasticsearch v9	opensearch-py / @opensearch-project/*
Licence	Elastic Licence 2.0 / SSPL / AGPL	Apache 2.0

Running both side by side is the point: the lab answers “how does Elasticsearch behave”, while OpenSearch stays the system of record for the platform.

Endpoints

	URL	Host port
Elasticsearch	https://dev-elastic.logrite.ai	9201 → 9200
Kibana	https://dev-kibana.logrite.ai	5602 → 5601

Credentials are not published here — this site is publicly reachable. They are in ELASTICSEARCH.md and CREDENTIALS.md §6 in the private LogriteMasterControl repo.

Note

9200 and 5601 belong to OpenSearch, and 9300 — Elasticsearch’s conventional transport port — is published by AI Service on this host. That is why the lab sits on 9201/5602 and publishes no transport port; a single-node cluster does not need one.

How it is configured

Both are Coolify applications with build_pack=dockerimage: stock upstream images configured entirely through environment variables, with no Dockerfile and no git repo behind them. This is the same shape as the opensearch and opensearch-dashboards apps.

Setting	Value	Why
discovery.type	single-node	One node, no cluster formation
xpack.security.enabled	true	Authentication is enforced; unauthenticated requests get 401
xpack.security.http.ssl.enabled	false	See below
ES_JAVA_OPTS	-Xms2g -Xmx2g	Matches the OpenSearch heap
Container memory limit	4 GB (ES) · 2 GB (Kibana)	The dev VM has no swap, and a container’s reported memory includes reclaimable page cache
Network alias	elasticsearch · kibana	Kibana reaches ES at http://elasticsearch:9200

Why HTTP on the wire, unlike OpenSearch

Elasticsearch 9 defaults to self-signed TLS on its HTTP layer. That forces --insecure, a CA file, or verificationMode: none into every client — the friction that OpenSearch’s demo certificates already impose across this platform. The lab disables HTTP-layer TLS instead and lets Cloudflare terminate TLS at the tunnel edge, so traffic is encrypted where it crosses the internet and no client needs special handling. Authentication is unaffected and stays on.

Caution

There is no Cloudflare Access policy in front of these hostnames, so the elastic password is the only control on an internet-facing cluster. Acceptable for a scratch cluster; not acceptable for anything real.

Gotchas

Note

A single node makes replicas impossible. Any index created with the default number_of_replicas: 1 can never allocate its replica, so the cluster reads yellow — that is expected, not a fault. Fix an index with PUT /my-index/_settings {"index":{"number_of_replicas":0}}.

Note

Kibana cannot run as the elastic superuser — it refuses by design. It uses a separate kibana_system account whose password must match both the Kibana app’s ELASTICSEARCH_PASSWORD and the value set via POST /_security/user/kibana_system/_password.

Note

Kibana’s three encryption keys are pinned deliberately. Without XPACK_SECURITY_ENCRYPTIONKEY, XPACK_REPORTING_ENCRYPTIONKEY and XPACK_ENCRYPTEDSAVEDOBJECTS_ENCRYPTIONKEY, Kibana mints new keys on every boot and silently loses saved objects — dashboards vanish with no error.

Note

Elasticsearch takes roughly 50 seconds to answer after a restart, and binds its port well before it will serve requests. A 000 right after a restart means “still starting”; a 503 with no_shard_available_action_exception means shards are still recovering. Neither is a fault.

Rebuilding it

ops/elasticsearch/install.sh in LogriteMasterControl recreates both apps, their environment, volumes, DNS records and tunnel ingress rules from nothing. It is idempotent.

That script exists because a Coolify application lives only as rows in the coolify-db container, and that database has been lost before — the 2026-08-03 host reflash destroyed every app definition on the machine.