OpenSearch

Last reviewed Aug 26, 2026 · 887 words

OpenSearch costs about 2 GB of RAM before it has indexed a single document, and that number is the honest starting point for any self-hoster considering it. A 1 GB JVM heap plus the operating system page cache the engine relies on is the floor; the catalogue's 2,048 MB minimum and "Hard" rating are not pessimistic. In exchange you get the Apache-2.0 fork of Elasticsearch 7.10 and Kibana, with full-text search, aggregations, anomaly detection, alerting, and an API that a large amount of existing software already speaks. Whether that trade is worth it depends on whether you need search or just logs, and I will come back to that.

What the fork is and is not

OpenSearch began in 2021 when Elastic moved Elasticsearch and Kibana off the Apache licence; Amazon forked the last Apache-licensed release, 7.10.2, and it has been developed under the OpenSearch Software Foundation since. The API is compatible with the Elasticsearch 7.x API, which is why Graylog, Fluentd, Logstash, and most client libraries work with it. It is not compatible with newer Elasticsearch-only features, and Elastic's official client libraries check the server product header and refuse to talk to it, so you use the OpenSearch clients instead. If you are choosing between the two for a fresh install, the Elasticsearch alternatives page has the licence side of the argument; technically they have diverged but remain close enough that most tutorials for one still apply to the other.

A single-node compose that starts on the first try

services:
  opensearch:
    image: opensearchproject/opensearch:latest
    environment:
      - discovery.type=single-node
      - OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=ChangeMe-To-Something-Strong-1
    ulimits:
      memlock: { soft: -1, hard: -1 }
      nofile: { soft: 65536, hard: 65536 }
    volumes:
      - opensearch-data:/usr/share/opensearch/data
    ports:
      - "9200:9200"
    restart: unless-stopped

  dashboards:
    image: opensearchproject/opensearch-dashboards:latest
    environment:
      - OPENSEARCH_HOSTS=["https://opensearch:9200"]
    ports:
      - "5601:5601"
    depends_on: [opensearch]

volumes:
  opensearch-data:

Two things break this on a fresh host. First, the kernel setting: sysctl -w vm.max_map_count=262144 (and persist it in /etc/sysctl.d/), or the node refuses to bootstrap. Second, the admin password: recent releases refuse to start with a weak or missing OPENSEARCH_INITIAL_ADMIN_PASSWORD, and the security plugin is on by default with self-signed TLS, so the first check is curl -ku admin:YourPassword https://localhost:9200. Pin latest to a real version once it works; upgrades across major versions need reading the notes.

Heap and disk have rules you cannot skip

Give the JVM half the machine's RAM and no more, and never above roughly 31 GB, because past that the JVM loses compressed object pointers and gets slower with more memory. The other half is the page cache that makes searches fast. On disk, the engine watches free space: at 85 percent used it stops allocating new shards to the node, at 90 percent it starts moving them away, and at 95 percent it marks indices read-only, which shows up as mysterious write failures in whatever is feeding it. For logs, set an Index State Management policy on day one that rolls indices daily and deletes them after 14 or 30 days. Without it the disk fills, the flood-stage watermark trips, and you learn the recovery command at the worst time.

Where it fits with Graylog, Fluentd, and Grafana

Graylog uses OpenSearch as its storage backend and adds inputs, a query UI, and alerting that many people prefer to Dashboards. Fluentd and Fluent Bit both have native opensearch outputs. Grafana has an OpenSearch data source, so the same Grafana that shows your Prometheus metrics can query logs here, though Dashboards remains the better tool for ad hoc exploration. The observability plugins (trace analytics, anomaly detection, the alerting monitors) are where OpenSearch pulls ahead of a plain Elasticsearch 7.10 install and are worth turning on if you are running it anyway.

When something smaller is the right answer

Most homelabs want logs, not search. Loki indexes only labels and stores compressed log chunks, runs comfortably in a few hundred megabytes, and pairs with Grafana natively; for "show me nginx errors from last night" it is the better tool and a fraction of the cost. For search on a website or an application, Meilisearch runs in tens of megabytes, returns typo-tolerant results in milliseconds, and needs no cluster tuning; the Elasticsearch vs Meilisearch comparison applies to OpenSearch word for word. OpenSearch earns its 2 GB when you need real full-text queries and aggregations over a large corpus, or when a tool you have already chosen (Graylog, a SIEM, an application with an ES dependency) requires it.

What I'd do

Loki for logs by default. OpenSearch only when a dependency demands it or the query needs are real, and then as a single node with a 1 GB heap on a box with at least 4 GB, vm.max_map_count set, an ISM policy that deletes after 30 days, and Graylog in front if humans will be reading the logs daily. Snapshot the data directory or use the snapshot API to an S3-compatible bucket weekly, and pin the version so an unattended pull cannot walk you across a major upgrade.