What the host has to provide
OpenSearch publishes no minimum machine. What it publishes are host settings and two storage rules, and they decide the hardware for you.
| Resource | What the OpenSearch documentation says | Where |
|---|---|---|
| JVM heap | Set initial and maximum heap to half of the available system memory as a starting point; on dedicated hosts it can be raised to suit the workload | Debian and RPM install guides |
| Heap default | -Xms1g -Xmx1g when you set nothing, and it overrides percentage flags | Important settings |
| Memory maps | vm.max_map_count at least 262144 for production on Linux, on the host even under Docker | Important settings |
| Swap | Disable it; bootstrap.memory_lock=true keeps the heap out of swap | Important settings, Docker guide |
| Open files | nofile limit of 65536 for the OpenSearch user | Important settings |
| Storage | SSDs installed on the host where possible; avoid a network file system for node storage | Installing OpenSearch |
From here the arithmetic is our own, not the project's: a 32 GB machine starts with -Xms16g -Xmx16g. How much index a given heap carries depends on your mappings, shard count and queries, so measure with your own data before settling on a size.
Ports, and which ones stay private
| Port (TCP) | Component | Exposure on a single server |
|---|---|---|
| 9200 | REST API | 127.0.0.1; if your application runs on another machine, open 9200 only to that machine's address |
| 9300 | Node-to-node transport | Only with a second node, and then open only to your other nodes' IPs |
| 9600 | Performance Analyzer | 127.0.0.1 |
| 5601 | OpenSearch Dashboards | 127.0.0.1, reached over an SSH tunnel |
OpenSearch uses no UDP. The Debian guide notes that a fresh package install is not bound to a network interface and cannot be reached by other hosts; setting network.host: 0.0.0.0 binds every interface, including the public one, and also switches on the production bootstrap checks. On a server with a public address, keep 9200 on loopback, or open it only to your application server's address, and put your application, or an authenticating proxy, in front of it.
Which of our machines fit
Size memory first, then disks. Every line in the dedicated server catalogue is a whole machine with root, no hypervisor and no other tenant, so the heap you set and the page cache around it are not competing with anyone's workload. The port is unmetered, which matters when log shippers write all day and snapshots copy indices off the box.
- Small search index or a staging node: the 16-core Xeon D-1587 cartridge, with 16 to 128 GB and an NVMe-SSD; the Xeon E-2286M in Bucharest, 32 to 64 GB on two NVMe drives.
- Log analytics with long retention: the dual-socket lines, Xeon Gold 6130 or E5-2630L v3, which take 16 GB up to 1 TB of memory. Choose SSDs in the configurator, or see the NVMe dedicated servers.
- A build to your own drive layout: AMD EPYC with 32 GB to 1 TB, built to order in 4 to 24 hours. Racked machines are handed over in about 30 minutes once payment is approved.
Every racked single-, dual- and quad-socket server has an out-of-band console (HPE iLO, Dell iDRAC or a Supermicro BMC), which is how you get back in after a firewall rule locks out SSH. Use an x86 line: the X-Gene ARM cartridge installs only Ubuntu 16.04 and 18.04. Five cities are listed on our data centre page; put the node next to the applications that query it.
Installing from the APT repository
The Debian package runs on Debian-based distributions such as Ubuntu and installs a systemd service. These are the commands from the official guide, preceded by the kernel setting. Since 2.12, a new install that sets up the demo security configuration needs OPENSEARCH_INITIAL_ADMIN_PASSWORD: between 8 and 100 characters, with at least one upper-case letter, one lower-case letter, one digit and one special character, rated strong or higher by zxcvbn and not similar to admin, or the demo security setup fails and the node does not start.
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
sudo apt-get update && sudo apt-get -y install lsb-release ca-certificates curl gnupg2
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://artifacts.opensearch.org/publickeys/opensearch-release.pgp \
| sudo gpg --dearmor -o /etc/apt/keyrings/opensearch.gpg
echo "deb [signed-by=/etc/apt/keyrings/opensearch.gpg] https://artifacts.opensearch.org/releases/bundle/opensearch/3.x/apt stable main" \
| sudo tee /etc/apt/sources.list.d/opensearch-3.x.list
sudo apt-get update
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD='replace-with-a-strong-password' apt-get install opensearch
sudo systemctl enable opensearch
sudo systemctl start opensearch
# -u admin with no password makes curl prompt for it
curl https://localhost:9200 -u admin --insecure
Typed inline, the password is recorded in your shell's history file and shows up in ps output for as long as apt runs. Remove the line from history afterwards (history -d with its number) and change the admin password once your own security configuration is in place.
- Set the heap in
/etc/opensearch/jvm.options:-Xmsand-Xmxto the same value, half the RAM to start. Declare it there or inOPENSEARCH_JAVA_OPTS, never both. - In
/etc/opensearch/opensearch.yml, setdiscovery.type: single-nodeif you bind a non-loopback address, otherwise the discovery bootstrap check stops the service. - Restart with
sudo systemctl restart opensearchand repeat the curl check.
The security plugin and its demo configuration
The Security plugin is on by default. The package install runs a demo configuration: self-signed demo certificates, internal users with known passwords, HTTPS on 9200. The OpenSearch docs say plainly that it is intended for testing only. That is why the curl above needs --insecure, and why a plain http:// request gets an empty reply.
Before real data goes in, the production checklist in the docs asks you to: replace the demo certificates with ones from your own certificate authority; choose how users authenticate (the internal user database, SAML, OpenID Connect or LDAP); map users and backend roles to roles; and change or remove the demo internal users. From 3.7, DISABLE_INSTALL_DEMO_CONFIG=true at install time skips the demo setup when you will configure security by hand. Turning the plugin off entirely is documented for testing and development only.
OpenSearch Dashboards over an SSH tunnel
Dashboards is a separate package, opensearch-dashboards, from its own APT repository, and it must run the same version as the cluster. Like OpenSearch, it binds to localhost after installation. Leave it there and reach it from your workstation with ssh -L 5601:127.0.0.1:5601 followed by your login and the server's address, then open http://localhost:5601 and sign in as admin. Setting server.host: 0.0.0.0 publishes it to the internet; for a team, front it with a TLS proxy that does its own authentication instead.
Snapshots, kept off the data disk
The docs are blunt: copying a node's data directory is not a consistent backup, and snapshots are the only reliable way to back up a cluster. Snapshots are incremental, so frequent ones cost little extra disk. Register a repository first. A file system repository on the same disks as the index does not survive a disk failure, so mount storage from another machine at the path.repo location, or install the repository-s3 plugin and point it at an S3-compatible store such as a MinIO server.
# /etc/opensearch/opensearch.yml
path.repo: ["/mnt/snapshots"]
Mount the remote storage at /mnt/snapshots. Our own step, not in the OpenSearch guide: give the opensearch user ownership with sudo chown opensearch:opensearch /mnt/snapshots, then restart with sudo systemctl restart opensearch.
curl -X PUT https://localhost:9200/_snapshot/my-fs-repository -u admin --insecure \
-H 'Content-Type: application/json' \
-d '{"type": "fs", "settings": {"location": "/mnt/snapshots"}}'
curl -X PUT 'https://localhost:9200/_snapshot/my-fs-repository/snapshot-1?wait_for_completion=true' \
-u admin --insecure
For a schedule and automatic deletion of old snapshots, use Snapshot Management inside OpenSearch rather than a cron job. Delete snapshots through the API, not by removing files, because incremental snapshots share data. Each index in a snapshot restores only into the major version that created it or the next one, and never into an older OpenSearch.
When one server is the wrong answer
One machine is one node. The production checklist calls for several nodes, including dedicated cluster manager nodes, so the cluster stays available when a node fails; a single server cannot give you that, however large it is. Use it for a search index you can rebuild, a log store with snapshots elsewhere, or staging. For high availability, rent several machines in one city and join them over 9300. We sell no private network linking servers, so cluster traffic crosses public IPs: leave TLS switched on and firewall 9300 to the addresses of your own nodes. And if your data is mostly numeric events aggregated by column rather than text you search, a columnar analytics database is the better tool; for a relational store, see the PostgreSQL dedicated server page.
Questions
How much RAM should a self-hosted OpenSearch node have?
The install guides give a rule, not a number: start the JVM heap at half of the available system memory, with -Xms and -Xmx equal, and raise it on a dedicated host if the workload needs it. Without a setting, OpenSearch runs with a 1 GB heap. How much data a heap holds depends on your shards, mappings and queries, so index part of your real data first and watch heap use before buying for the full set.
Can I run it in Docker on the same server?
Yes, the official images are opensearchproject/opensearch and opensearchproject/opensearch-dashboards. Set vm.max_map_count on the host, not in the container. Publish ports as 127.0.0.1:9200:9200 rather than 9200:9200: Docker writes its own firewall rules, so a plain -p mapping is reachable from the internet even when ufw denies the port. The docs describe their sample Compose files as for testing and development, not production.
Why will the node not start after I changed network.host?
Binding to anything other than localhost turns on the bootstrap checks. Two usually fail: vm.max_map_count below 262144, and missing discovery settings. On a single server set discovery.type: single-node; for a cluster set discovery.seed_hosts and cluster.initial_cluster_manager_nodes.
Is the demo security configuration safe to keep?
No. It uses self-signed demo certificates and internal users whose passwords are known, and the documentation states it is for testing only. Replace the certificates, set up authentication and roles, and change or remove the demo users before the node holds anything you care about.