Elasticsearch

Last reviewed Aug 26, 2026 · 831 words

Most self-hosters who install Elasticsearch did not need Elasticsearch. If the job is "search my app's records" or "search box on my site", Meilisearch does it in a fraction of the RAM with a fraction of the tuning, and the Elasticsearch vs Meilisearch comparison exists because this is the single most common oversizing mistake in the search category. Elasticsearch is the right tool when you need what it is actually for: log analytics over millions of documents, aggregations that slice data twelve ways, and a query DSL with 15 years of depth behind it. The catalogue's Hard rating is honest, and this guide is about paying that cost only where it buys something.

The 2 GB minimum is a demo, not a deployment

Elasticsearch runs in a JVM, and the JVM heap is the number that governs everything. The catalogue's 2048 MB floor will boot a node and index test data; a working single-node install doing log ingestion wants 4 to 8 GB of system RAM as a realistic starting point. Two heap rules are close to law. Give the heap at most 50% of the machine's RAM, because Lucene — the engine underneath — uses the other half as filesystem cache, and starving that cache makes queries slow in ways heap cannot fix. And keep the heap under about 30 GB even on huge boxes, below the threshold where the JVM loses compressed object pointers and larger heaps get less efficient. Recent versions size heap automatically from container limits, which makes the memory limit you set on the container the real tuning knob.

Three settings separate "crash loop" from "boring"

Nearly every failed first install traces to the same short list, so here is the single-node Docker shape that works:

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:9.0.0
    environment:
      - discovery.type=single-node
    ports:
      - "9200:9200"
    volumes:
      - ./esdata:/usr/share/elasticsearch/data
    deploy:
      resources:
        limits:
          memory: 4g
    restart: unless-stopped

The load-bearing pieces: discovery.type=single-node stops the node from waiting for a cluster that will never come; the host needs vm.max_map_count raised to 262144 (sysctl -w vm.max_map_count=262144, then make it permanent in /etc/sysctl.conf) or the node refuses to start; and the memory limit both contains the JVM and informs its automatic heap sizing. Pick the current image tag from the official docs rather than trusting any blog post's version, this one included. Port 9200 is the REST API; 9300 exists for node-to-node traffic and single-node installs can ignore it.

Security is on by default now, and that's good

Older tutorials assume the anything-goes Elasticsearch of the 2010s, the era that produced a steady news cycle of open clusters leaking data on port 9200. Modern releases generate passwords and enable TLS on first start, and the right move is to keep it that way even on a LAN — an unauthenticated cluster full of your logs is exactly the kind of internal service that turns a small compromise into a large one. Bind it to localhost or a private interface, keep the built-in auth, and never port-forward 9200 to the internet under any circumstances.

You'll want the rest of the family, and it isn't free (in RAM)

Elasticsearch alone is a JSON API. Practical use nearly always adds Kibana for dashboards and query building, and log pipelines add a shipper (Filebeat or Logstash). Kibana wants its own gigabyte-plus, so a "just logs" stack lands around 6 GB of RAM before your first dashboard. For homelab log search specifically, weigh Grafana Loki, which indexes labels rather than full text and runs far lighter; Elasticsearch wins when you genuinely need full-text queries and heavy aggregations over the log body itself.

Know the license story before you build on it

The catalogue lists Elastic License 2.0: source-available, fine to self-host and use, but not fully open source by the classic definition, a 2021 change that produced the OpenSearch fork now developed independently under Apache-2.0. For a homelab this changes nothing day to day. For a product you might redistribute or resell as a service, read the license terms yourself, and know OpenSearch exists as the drop-in-ish escape hatch with a diverging feature set.

What I'd do

Site or app search: Meilisearch, no contest, and skip everything above. Log analytics or serious aggregations: one Elasticsearch node exactly as configured above on a box with 8 GB, vm.max_map_count set, security left on, Kibana beside it, and index lifecycle management configured in week one so old indices delete themselves before the disk fills — that omission is the most common month-two failure. Stay single-node until the data genuinely outgrows one machine; a cluster is a part-time job, and most homelabs never need one.