Installing Elasticsearch on Cloudways (Complete Guide)

Installing Elasticsearch on Cloudways is still a console toggle: go to Server Management → Settings & Packages → Packages, find the search engine entry, pick a version and enable it. The catch is RAM. Elasticsearch is a Java service that wants a gigabyte to itself, and enabling it on a 1 GB server will get something killed.

One piece of context worth having before you start. Cloudways has been a DigitalOcean company since 2022, and the classic server-based product is now branded Cloudways Flexible. That is the one with the search engine package. Cloudways Autonomous, the autoscaling WordPress product, does not give you server-level package control, so everything below assumes Flexible.

Is Elasticsearch still a one-click package on Cloudways?

Yes. It appears in Manage Services and in the Packages tab as a “Search Engine” entry covering both Elasticsearch and OpenSearch, and Cloudways markets it as one-click activation. The path is Servers → your server → Server Management → Settings & Packages → Packages, then choose a version and click install or enable.

On pricing: today it is presented as an optional package on a server you already pay for, not as a line-item add-on with its own catalog price. The real cost is the RAM you have to buy to run it, which is usually a jump of one or two server tiers. Whatever your account shows at the moment you click enable is the number to trust — do not take a figure from a 2021 tutorial.

The RAM reality, before you enable anything

This is where most Cloudways Elasticsearch stories go wrong. Your server is already running Apache, Nginx, PHP-FPM, MySQL or MariaDB, Varnish, Redis and Memcached. Elasticsearch then asks for a Java heap on top, and Elastic’s own rule is that heap should be no more than 50% of total memory, with Xms and Xmx set to the same value. Do that arithmetic on a 2 GB box and there is nothing left for the database.

The table below is my practical sizing, not a vendor spec sheet. It assumes the app, the database and search all share one server, which is the normal Cloudways setup.

Two rules behind those numbers. Heap stays at or below half of RAM because Lucene uses the operating system’s file cache for the rest, and that cache is what makes search fast. And heap never goes above roughly 31 GB, because past that the JVM loses compressed object pointers and you get less usable memory from more heap.

Route A: enable the package from the console

1. Resize the server first if you are under 4 GB. Cloudways vertical scaling is a reboot, so do it before you have traffic depending on the service.
2. Go to Servers → your server → Server Management → Settings & Packages and open the Packages tab.
3. Find the search engine entry, select the version you want, and click to install or enable it.
4. Wait for the platform to finish. It installs the service and starts it on port 9200 bound to the local interface.
5. SSH in and confirm the service is actually up before you touch your application.

curl -s http://127.0.0.1:9200
curl -s http://127.0.0.1:9200/_cluster/health?pretty
free -m

A healthy single-node install returns a JSON body with the version number and a cluster status of green or yellow. Yellow is normal on one node — replica shards have nowhere to go. Then run free -m and look at how much memory is genuinely free, not just cached.

Route B: install Elasticsearch manually over SSH

Use this when you need a current major version. Cloudways servers run Debian 12, so Elastic’s APT repository works directly. The Debian package bundles its own JDK, so you do not install Java separately.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo apt-get install apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-9.x.list
sudo apt-get update && sudo apt-get install elasticsearch

Set the kernel limit next. Elasticsearch maps a lot of files and Debian’s default is far too low:

echo "vm.max_map_count=1048576" | sudo tee -a /etc/sysctl.conf
sudo sysctl --system
sysctl vm.max_map_count

Then pin the heap. Do not edit jvm.options directly — package upgrades overwrite it. Drop your own file into jvm.options.d/ instead, and it must end in .options:

sudo tee /etc/elasticsearch/jvm.options.d/heap.options > /dev/null <<'EOF'
-Xms1g
-Xmx1g
EOF
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service

That systemctl enable line is the one people skip, and it is why the service disappears after a reboot. The Debian package deliberately does not enable itself.

Keep it on localhost, and add authentication

Out of the box a single node binds only to loopback addresses, and you should leave it that way. An Elasticsearch instance reachable on the public internet is an open database: anyone can read every document, delete every index, and in some configurations write to it. Ransom attacks against exposed clusters have been an ongoing pattern for years. Your app talks to search over 127.0.0.1, so there is no reason to bind anywhere else.

Check what is actually listening, and check from outside too:

sudo ss -tlnp | grep 9200
curl -m 5 http://YOUR_SERVER_IP:9200

The first command should show 127.0.0.1:9200 and not 0.0.0.0:9200. The second, run from your laptop, should time out. If it returns JSON, stop and fix the binding before you do anything else. On the Cloudways side, Settings & Packages → Advanced → Nginx also has IP allow-listing if you ever need controlled remote access.

On authentication, the behavior depends on the major version. Elasticsearch 8 and later turn security on by default: TLS on the HTTP layer with a self-signed certificate and a generated password for the elastic superuser. The password is not printed when the service starts under systemd, so you reset it:

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic
curl -k -u elastic:YOUR_PASSWORD https://127.0.0.1:9200

Note the https and the -k. Plain curl localhost:9200 failing on version 8 or later usually means security is working, not that the install is broken. On Elasticsearch 7.17 security is off by default and you enable it with xpack.security.enabled: true in /etc/elasticsearch/elasticsearch.yml, then set passwords with the setup utility. Basic authentication is free in the basic license — there is no reason to run without it.

Connecting a WordPress or Magento app

For WordPress the standard bridge is ElasticPress. Install and activate the plugin, then define the host in wp-config.php:

define( 'EP_HOST', 'http://127.0.0.1:9200' );

Then run the plugin’s setup wizard and index your content. On a small server, index during a quiet hour — a full reindex is the most memory-hungry thing the service will ever do, and it is when OOM kills happen.

Magento configures its search engine under Stores → Configuration → Catalog → Catalog → Catalog Search, pointing at the same local host and port. Check your Magento version’s requirements first, because Adobe has been moving off Elasticsearch: the 2.4.9 requirements list OpenSearch 3 and no longer list Elasticsearch at all, while 2.4.8 accepts Elasticsearch 8 or OpenSearch 3. Neither of those lines up neatly with the 7.17, 8.11 and 2.19 that Cloudways ships, so verify the matrix before you commit to the console route.

Index maintenance

Search indexes are not fire-and-forget. Three habits keep a small server healthy:

curl -s 'http://127.0.0.1:9200/_cat/indices?v&s=store.size:desc'
curl -s 'http://127.0.0.1:9200/_cat/allocation?v'
curl -X DELETE 'http://127.0.0.1:9200/old-index-name'

First, look at index sizes monthly. Plugins that log queries or store analytics inside Elasticsearch grow quietly until the disk fills. Second, delete abandoned indexes — a botched reindex often leaves an orphan holding a full copy of your catalog. Third, if you generate time-based indexes, set up an index lifecycle policy rather than deleting by hand, and never run a force merge on a live index during business hours.

Elasticsearch or OpenSearch?

OpenSearch is the AWS-led fork of Elasticsearch 7.10, licensed Apache 2.0, and it is why the Cloudways package covers both. The licensing gap that created the fork has narrowed: Elastic added AGPLv3 as an option in September 2024 alongside the Elastic License 2.0 and SSPL, so Elasticsearch is open source again by the OSI definition, though the default distribution still ships under the Elastic License.

Practical guidance. Choose OpenSearch if your application explicitly targets it (increasingly true for Magento), if you want Apache 2.0 with no license conversation, or if your host’s supported version is newer on the OpenSearch side. Choose Elasticsearch if your plugin ecosystem is built around it, ElasticPress being the obvious case. For a single-node search backend behind a CMS, you will not notice a functional difference.

Troubleshooting

The service won’t start after a reboot

Almost always a missing systemctl enable elasticsearch.service. Run systemctl is-enabled elasticsearch to confirm. If it is enabled but still fails at boot, read journalctl -u elasticsearch -n 100 — on small servers the usual cause is that MySQL grabbed memory first and the JVM could not reserve its heap. Lower the heap, or resize the server.

“max virtual memory areas vm.max_map_count [65530] is too low”

A bootstrap check refusing to let the node start. The message asks for at least 262144; Elastic’s current documentation specifies 1048576, so set the higher value in /etc/sysctl.conf as shown above and run sudo sysctl --system. Setting it with sysctl -w alone does not survive a reboot, which is how this error comes back three weeks later.

Heap OOM kills

Two different failures wear the same clothes. A JVM OutOfMemoryError in the Elasticsearch log means the heap is too small for your queries — usually deep aggregations or an oversized bulk indexing batch. The kernel OOM killer, visible in dmesg, means the whole server is out of memory and Linux picked a victim, often MySQL rather than Java.

sudo journalctl -u elasticsearch --since "1 hour ago" | grep -i "outofmemory"
sudo dmesg -T | grep -i "killed process"

The fix for the first is a bigger heap or smaller batches. The fix for the second is more RAM. Do not reach for a large swap file as a workaround — swapping a JVM heap turns a fast search backend into a slow one and hides the real problem.

Version mismatch with a client plugin

Symptoms are a plugin that connects and then fails on the first query, or errors about an unsupported API or a missing mapping type. Elasticsearch removed mapping types in 7.x and changed several APIs again in 8.x, so a client library written for one major version frequently cannot talk to the next. Check the version at both ends — curl 127.0.0.1:9200 tells you the server, the plugin’s readme tells you what it supports — and match them before debugging anything else. This is the single strongest argument for the manual install: you get to choose the version instead of accepting what the panel offers.

Frequently asked questions

How much RAM does Elasticsearch need on Cloudways?

Plan on 4 GB total server RAM as a minimum for production with a 1 GB heap, and 8 GB if you have a real catalog or run frequent reindexes. 2 GB works for a development server with a small index. On 1 GB, enabling search will get MySQL or PHP-FPM killed by the kernel.

What port does Elasticsearch use, and should I open it?

Port 9200 for the HTTP API and 9300 for node-to-node traffic. Do not open either in your firewall. Your application connects over 127.0.0.1, so there is no legitimate reason for 9200 to be reachable from the internet.

Can I run Elasticsearch on a Cloudways server alongside Magento?

Yes, and it is the normal setup. Size for both: Magento’s own PHP and MySQL footprint plus a search heap means 8 GB is a realistic floor. Check that the version Cloudways offers is one your Magento release supports, since Adobe now lists OpenSearch rather than Elasticsearch for the newest versions.

Is OpenSearch a drop-in replacement for Elasticsearch?

For basic search behind a CMS, largely yes — OpenSearch forked from Elasticsearch 7.10 and keeps API compatibility with that era. It is not a drop-in for clients written against Elasticsearch 8 or 9 APIs, and some tooling is fussy. Check your plugin’s documentation rather than assuming.

Do I need Elasticsearch at all for a small site?

Probably not. Under a few thousand posts or products, your database’s own full-text index is faster to set up, costs nothing in RAM, and has nothing to monitor. Add a search engine when you need faceted filtering, typo tolerance or relevance tuning — not because it sounds professional.

How do I monitor Elasticsearch on a small server?

Start with _cluster/health and _cat/nodes on a cron, alerting on anything that is not green or yellow. If you want graphs, a self-hosted dashboard works fine — our walkthrough for installing Grafana on a Hostinger VPS covers the same pattern of running a JVM-adjacent service on a small box.

Wrapping up

Installing Elasticsearch on Cloudways is easy and sizing it is not. The console route is genuinely one click, but it hands you Elasticsearch 7.17 or 8.11, or OpenSearch 2.19, all of them well behind current upstream, and 7.x is already end of life. If your stack is happy on those, enable the package on a server with 4 GB or more, set the heap to a quarter of RAM, confirm 9200 is bound to loopback, and get on with your day.

If you need a current version, install it yourself from Elastic’s Debian package documentation, set vm.max_map_count permanently, and accept that you now own the upgrades. For anything with real query volume, the honest recommendation is to stop sharing one server: put search on its own machine, or run it as a container you can version independently — the same reasoning that pushes teams toward Helm and Kubernetes for stateful services. And if the app in front of it is a PHP framework rather than WordPress, the console paths in our guide to installing CakePHP on Cloudways and the platform comparison in running CakePHP on cloud hosting will save you a second round of trial and error.