How to Install Elasticsearch 8 on Debian 13, 12 and 11

Existing Elastic Stack deployments often need Elasticsearch 8 even after Elasticsearch 9 is available, especially when clients, plugins, or cluster upgrade plans are pinned to the 8.x branch. You can install Elasticsearch 8 on Debian from Elastic’s official APT repository and run it as a systemd service with authentication and TLS enabled by default.

Elastic’s 8.x APT repository currently provides Elasticsearch 8.19.15 packages for amd64 and arm64. The same repository path works across Debian 13 (Trixie), Debian 12 (Bookworm), and Debian 11 (Bullseye), while Elastic’s version policy lists Elastic Stack 8.x support through July 15, 2027.

Install Elasticsearch 8 on Debian

The Elastic APT repository installs the Debian package, creates the elasticsearch user and group, enables security auto-configuration, and leaves service startup under your control. Use this official repository path for most Debian servers.

Use only one Elastic 8 repository source on the same host. Do not keep an extrepo-created Elastic source and the manual DEB822 source together, because duplicate sources with different Signed-By paths can break APT updates.

Update APT and Install Prerequisites

Refresh package metadata, then install the tools needed to download and store Elastic’s signing key. Minimal Debian systems may not include curl, gpg, or certificate packages by default.

sudo apt update
sudo apt install curl gpg ca-certificates

These commands use sudo for package-manager and system-file changes. Run them from a user account that has administrative privileges on the Debian host.

Import the Elastic Signing Key

Store the Elastic signing key in /usr/share/keyrings/ so the key is scoped to the Elastic source file instead of being trusted globally.

sudo install -d -m 0755 /usr/share/keyrings
curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor --yes -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo chmod 0644 /usr/share/keyrings/elasticsearch-keyring.gpg

The chmod command keeps the keyring readable by APT while leaving the file owned by root.

Confirm the key fingerprint before adding the repository. Elastic’s current Elasticsearch signing key fingerprint is 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4.

gpg --show-keys --with-fingerprint /usr/share/keyrings/elasticsearch-keyring.gpg

Add the Elasticsearch 8 APT Source

Create a DEB822 source file for Elastic’s 8.x APT repository. The DEB822 stanza uses the same Elastic repository and signing key as Elastic’s package documentation, but stores the repository in a .sources file for easier auditing and cleanup. The stable suite is Elastic’s repository suite name, not a Debian codename, so do not replace it with trixie, bookworm, or bullseye. The source file limits APT to amd64 and arm64 because the elasticsearch package is published for those architectures.

printf '%s\n' \
'Types: deb' \
'URIs: https://artifacts.elastic.co/packages/8.x/apt' \
'Suites: stable' \
'Components: main' \
'Architectures: amd64 arm64' \
'Signed-By: /usr/share/keyrings/elasticsearch-keyring.gpg' | sudo tee /etc/apt/sources.list.d/elasticsearch-8x.sources >/dev/null

Refresh APT so Debian can read the new repository metadata.

sudo apt update

Verify the Candidate and Install Elasticsearch

Check the package policy before installation. The candidate should begin with 8., and the source line should reference https://artifacts.elastic.co/packages/8.x/apt. If the candidate begins with 9., another Elastic 9.x source is still enabled and should be disabled before installing Elasticsearch 8.

apt-cache policy elasticsearch

Relevant output includes:

  Candidate: 8.19.15
     8.19.15 500
        500 https://artifacts.elastic.co/packages/8.x/apt stable/main amd64 Packages

Install Elasticsearch after the candidate check points at the Elastic 8.x repository.

sudo apt install elasticsearch

The package is large because it bundles its own Java runtime under /usr/share/elasticsearch/jdk. During installation, Elastic’s post-install scripts create TLS material, enable authentication, and print the initial password for the elastic built-in superuser. Store that password securely when it appears.

--------------------------- Security autoconfiguration information ------------------------------
Authentication and authorization are enabled.
TLS for the transport and HTTP layers is enabled and configured.
The generated password for the elastic built-in superuser is : [save this generated value]

The Debian package does not start Elasticsearch automatically after installation. This gives you time to review memory, network, and security settings before the first service start.

Start and Enable Elasticsearch

Reload systemd, enable Elasticsearch for future boots, and start the service.

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service

Check both the runtime state and the boot-time enablement state.

systemctl is-active elasticsearch.service
systemctl is-enabled elasticsearch.service

Expected output:

active
enabled

Reset the Elastic Password if Needed

Elasticsearch 8 does not use a reusable static default password. The initial elastic password is generated during security auto-configuration, and each reset creates a new value.

If the installation password scrolled away or you want a fresh value, reset the elastic user after the service is running. The -b option generates a new password without interactive prompts; use -i instead when you want to type your own password.

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -b

Password for the [elastic] user successfully reset.
New value: [save this generated value]

Test the Local HTTPS API

Elasticsearch 8 enables HTTPS and authentication during security auto-configuration. Use the generated CA certificate and let curl prompt for the elastic password instead of putting the password in your shell history. The sudo prefix is required because /etc/elasticsearch/certs/http_ca.crt is readable by root and the elasticsearch group.

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200

Relevant output includes the cluster name, the installed Elasticsearch 8 version, build_type set to deb, and the standard tagline.

{
  "cluster_name" : "elasticsearch",
  "version" : {
    "number" : "8.19.15",
    "build_type" : "deb"
  },
  "tagline" : "You Know, for Search"
}

Check single-node health when the API responds.

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic 'https://localhost:9200/_cluster/health?pretty'

Typical single-node output includes:

{
  "status" : "green",
  "number_of_nodes" : 1
}

A fresh single-node install can report green when all shards are assigned or yellow when replicas cannot be assigned to another node. Treat red as a failure state that needs log and shard-allocation checks.

Check the Installed Package Version

Use dpkg-query for installed package proof and apt-cache policy when you need to see both the installed version and the candidate source.

dpkg-query -W -f='${db:Status-Abbrev} ${Version}\n' elasticsearch
apt-cache policy elasticsearch

ii  8.19.15

Choose Elasticsearch 8 or Elasticsearch 9 on Debian

Use Elasticsearch 8 when an existing cluster, plugin, application client, or staged migration plan is tied to the 8.x branch. Use Elasticsearch 9 for new self-managed deployments that need the current major branch and have no 8.x compatibility requirement. The major branches use different APT paths, so do not switch between them as a routine package update.

Branch	Best Fit	Repository Path	Lifecycle Note
Elasticsearch 8.x	Existing Elastic Stack 8 clusters, plugin compatibility, client compatibility, staged major-version upgrades	`packages/8.x/apt`	Elastic lists 8.x support through July 15, 2027.
Elasticsearch 9.x	New deployments that are ready for the current major branch	`packages/9.x/apt`	Use a separate 9.x workflow because candidates, features, and upgrade planning differ.

Elasticsearch is not a Debian archive package in this workflow. Maintenance, support eligibility, and operating-system support follow Elastic’s version policy and support matrix, not Debian’s release lifecycle alone.

Resolve Debian Package Method Questions

Elastic publishes an APT repository and direct Debian package downloads. The APT repository is the better Debian server path because updates arrive through APT, the source file remains visible, and package policy checks show exactly where the candidate comes from.

If you only need an Elasticsearch 8 .deb for an offline or pinned-version workflow, use Elastic’s official downloads or past releases pages and verify the published checksum before installing the local package. Avoid old hostnames such as download.elasticsearch.org or stale pool URLs from search results for a maintained Debian install.

If you already manage third-party APT repositories with extrepo, keep that workflow in the dedicated Debian extrepo guide and verify the final Elastic source before installing. Do not configure extrepo and the manual DEB822 source for the same Elastic branch on one host.

Docker images are a separate deployment model. They change data paths, networking, service management, and upgrades, so keep container workflows separate from this host-managed systemd service.

Configure Elasticsearch Paths and JVM Settings

The Debian package uses standard Linux paths for binaries, configuration, data, logs, generated certificates, plugins, and package environment settings.

Path	Role
`/usr/share/elasticsearch/`	Elasticsearch home, binaries, bundled JDK, and plugins
`/etc/elasticsearch/`	Main configuration, including `elasticsearch.yml` and generated TLS files
`/etc/elasticsearch/certs/http_ca.crt`	Generated CA certificate for HTTPS API trust
`/etc/default/elasticsearch`	Package environment settings such as `ES_PATH_CONF` and restart-on-upgrade behavior
`/var/lib/elasticsearch/`	Index data, cluster state, and node data
`/var/log/elasticsearch/`	Elasticsearch logs

Edit the Main Configuration File

Most single-node development installs can start with the package defaults. When you need to change the cluster name, node name, paths, discovery behavior, or network binding, edit elasticsearch.yml and restart the service afterward.

sudo nano /etc/elasticsearch/elasticsearch.yml

For example, set explicit cluster and node names with plain YAML keys:

cluster.name: search-prod
node.name: debian-node-1

sudo systemctl restart elasticsearch.service
systemctl is-active elasticsearch.service

Adjust JVM Heap Size

Elasticsearch automatically sizes the JVM heap for many installations. If you need a fixed heap, put custom options in /etc/elasticsearch/jvm.options.d/ instead of editing the package-owned root jvm.options file. Set Xms and Xmx to the same value.

printf '%s\n' '-Xms2g' '-Xmx2g' | sudo tee /etc/elasticsearch/jvm.options.d/heap.options >/dev/null
sudo systemctl restart elasticsearch.service

Keep the heap under 50% of available memory and below the compressed ordinary object pointer threshold. Elastic documents 26 GB as safe on most systems, with about 30 GB possible on some systems.

Set vm.max_map_count for Production

The Elastic package attempts to configure virtual-memory settings during installation. On current Debian package installs, vm.max_map_count can be set to 262144, while Elastic’s current production guidance recommends 1048576 when the value is lower. Check the value before exposing the node beyond localhost or adding it to a cluster.

sudo sysctl vm.max_map_count

If the value is below 1048576, create a sysctl drop-in and reload system settings.

printf '%s\n' 'vm.max_map_count=1048576' | sudo tee /etc/sysctl.d/99-elasticsearch.conf >/dev/null
sudo sysctl --system
sudo sysctl vm.max_map_count

Elasticsearch treats non-loopback cluster networking as production mode and turns some startup warnings into hard failures. Review bootstrap-check messages carefully before changing more options.

Manage Elasticsearch Network Access on Debian

Do not assume the HTTP API is local-only after security auto-configuration. Verify the active listener, keep port 9200 source-restricted, and plan transport-port access on 9300 only for trusted cluster nodes that need it.

Check the Active Listener

Use ss to see which address owns port 9200. A listener such as 127.0.0.1:9200 is local-only; 0.0.0.0:9200 or :::9200 means the HTTP API is listening on external interfaces and needs host firewall and upstream network controls.

sudo ss -tlnp | grep ':9200'

If the binding is not what you expect, review http.host, transport.host, network.host, and discovery settings in /etc/elasticsearch/elasticsearch.yml.

Allow a Trusted Client IP with UFW

If another trusted host needs to reach the Elasticsearch HTTP API, restrict the firewall rule to that client, proxy, Kibana, Logstash, Beats, or application server address. Replace the example IP with your real client address. The Debian UFW guide covers broader firewall setup, and Nginx on Debian is a common reverse proxy option when you want to terminate TLS or centralize access controls.

sudo ufw allow from 192.168.1.50 to any port 9200 proto tcp
sudo ufw status numbered

Allow SSH before enabling UFW on a remote server, or you can lock yourself out of the Debian host.

Update Elasticsearch 8 on Debian

APT handles Elasticsearch 8 package updates from the same 8.x repository. Check the candidate first, apply the package upgrade, then restart a single-node install when appropriate.

sudo apt update
apt-cache policy elasticsearch
sudo apt install --only-upgrade elasticsearch

Restart a single-node service after the upgrade. For multi-node clusters, follow Elastic’s rolling-upgrade guidance and shard-allocation steps instead of restarting every node at once.

sudo systemctl restart elasticsearch.service
systemctl is-active elasticsearch.service

Troubleshoot Elasticsearch 8 on Debian

Package Is Missing or APT Cannot Locate Elasticsearch

Confirm that the source file exists, refresh metadata, and recheck the candidate.

The install failure usually looks like this:

E: Unable to locate package elasticsearch

sudo test -f /etc/apt/sources.list.d/elasticsearch-8x.sources && echo "source file exists"
sudo apt update
apt-cache policy elasticsearch

If the policy output does not show Elastic’s 8.x repository, recheck the URIs, Suites, Components, Architectures, and Signed-By fields in the source file.

Candidate Shows Elasticsearch 9 Instead of 8

The elasticsearch package name is shared by Elastic’s 8.x and 9.x repositories. If apt-cache policy elasticsearch shows a 9. candidate, find every enabled Elastic source and disable the unwanted 9.x entry before installing.

grep -R "artifacts.elastic.co/packages" /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
sudo apt update
apt-cache policy elasticsearch

Repository Is Not Signed or Key Verification Fails

A signing error usually means the key file is missing, unreadable, or not the same path used by Signed-By. It can also happen when an older one-line Elastic source is still present. Search duplicate source entries with the grep command.

Common error lines include:

NO_PUBKEY D27D666CD88E42B4
E: The repository 'https://artifacts.elastic.co/packages/8.x/apt stable InRelease' is not signed.

ls -l /usr/share/keyrings/elasticsearch-keyring.gpg
grep -R "artifacts.elastic.co/packages" /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
grep -R "Signed-By" /etc/apt/sources.list.d 2>/dev/null

Remove stale duplicate source files or fix the Signed-By path, then refresh APT again.

sudo apt update

curl Shows an SSL Certificate Error

An HTTPS request without the generated CA certificate fails because Elasticsearch uses its auto-generated HTTP CA by default.

curl: (60) SSL certificate problem: self-signed certificate in certificate chain

Use the CA certificate path and the elastic user instead.

sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200

Plain HTTP curl localhost:9200 Fails

A plain curl localhost:9200 request fails because Elasticsearch 8 enables TLS and authentication on the HTTP layer. Use https, the generated CA certificate, and the elastic user.

curl: (52) Empty reply from server

Disabling xpack.security.enabled or xpack.security.http.ssl.enabled allows plain HTTP only on isolated lab systems. Keep security enabled for shared, networked, and production hosts.

401 Unauthorized from the API

A 401 response means HTTPS is working, but Elasticsearch rejected the supplied credentials. This usually happens when the original generated password was lost, copied incorrectly, or replaced by a later reset.

{"error":{"type":"security_exception","reason":"unable to authenticate user [elastic]"},"status":401}

Reset the elastic password while the service is running, then repeat the HTTPS API request and let curl prompt for the new value.

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -b
sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200

curl Cannot Connect to Port 9200

A connection failure usually means the service is stopped, still starting, bound to a different address, or blocked by a local firewall rule.

curl: (7) Failed to connect to localhost port 9200: Could not connect to server

Check the service and listener before changing configuration.

systemctl is-active elasticsearch.service
sudo ss -tlnp | grep ':9200'
sudo journalctl -u elasticsearch.service --no-pager -n 40

Security Auto-Configuration Is Skipped

If package output says Skipping auto-configuration because security features appear to be already configured on what should be a fresh node, leftover data or configuration from an earlier Elasticsearch install may still exist. Do not delete these paths from a real cluster node casually; clean them only when you are intentionally rebuilding the node and have backups or snapshots.

sudo systemctl disable --now elasticsearch.service
sudo apt purge elasticsearch
sudo rm -rf /var/lib/elasticsearch
sudo rm -rf /var/log/elasticsearch
sudo rm -rf /etc/elasticsearch

After cleanup, reinstall from the Elastic 8.x source and watch for the security auto-configuration output that creates the generated password and /etc/elasticsearch/certs/http_ca.crt.

Password Reset Exits with Code 75

The password reset tool connects to the local Elasticsearch node. If it exits with code 75, confirm the service is active, the generated CA certificate exists, and the HTTPS API responds before retrying.

systemctl is-active elasticsearch.service
sudo test -f /etc/elasticsearch/certs/http_ca.crt && echo "CA certificate exists"
sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic https://localhost:9200

Service Fails or Bootstrap Checks Block Startup

Read the Elasticsearch service logs first. Bootstrap failures usually name the exact setting, resource limit, memory issue, or networking condition that needs attention.

sudo journalctl -u elasticsearch.service --no-pager -n 80
systemctl status elasticsearch.service

If the failure appears after changing network settings, review production-mode bootstrap checks before changing more options. If memory is the issue, reduce custom heap settings or increase system memory so the JVM, filesystem cache, and operating system all have room.

Port 9200 Is Already in Use

Identify the process already using the HTTP API port.

sudo ss -tlnp | grep ':9200'

Stop the conflicting service, change that service’s listener, or configure Elasticsearch to use a different HTTP port before restarting Elasticsearch.

Remove Elasticsearch 8 from Debian

Stop the service first, then purge the package. Keep data and configuration until you have confirmed backups, snapshots, or migration requirements.

sudo systemctl disable --now elasticsearch.service
sudo apt purge elasticsearch

Preview unused dependency cleanup before running it. Continue only if the package list is acceptable for your system.

sudo apt autoremove --dry-run

sudo apt autoremove

If you added the example UFW rule, remove it by number after checking the active firewall list. Replace 1 with the rule number shown on your host.

sudo ufw status numbered
sudo ufw delete 1

If you created the production vm.max_map_count drop-in only for Elasticsearch, remove it and reload sysctl settings.

sudo rm -f /etc/sysctl.d/99-elasticsearch.conf
sudo sysctl --system

Remove the Elastic 8.x APT source only if this system no longer needs Elasticsearch 8 packages. The cleanup also removes common legacy source filenames from older one-line or DEB822 setups when they still point to the same Elastic 8 repository. Remove the signing key only when no remaining Elastic source references the same keyring.

for source_file in \
    /etc/apt/sources.list.d/elasticsearch-8x.sources \
    /etc/apt/sources.list.d/elasticsearch.sources \
    /etc/apt/sources.list.d/elastic-8.x.list; do
    if [ -f "$source_file" ] && grep -q "artifacts.elastic.co/packages/8.x/apt" "$source_file"; then
        sudo rm -f "$source_file"
    fi
done
key_refs=$(
    { [ -f /etc/apt/sources.list ] && grep -H -E "elasticsearch(-keyring)?\.gpg" /etc/apt/sources.list; } 2>/dev/null
    grep -R -E "elasticsearch(-keyring)?\.gpg" /etc/apt/sources.list.d 2>/dev/null || true
)
if [ -z "$(printf '%s' "$key_refs" | tr -d '[:space:]')" ]; then
    sudo rm -f /usr/share/keyrings/elasticsearch-keyring.gpg
    sudo rm -f /usr/share/keyrings/elasticsearch.gpg
fi
sudo apt update
apt-cache policy elasticsearch

Delete local Elasticsearch data, logs, and configuration only when you are sure you no longer need the node’s indices, generated certificates, or local settings.

The cleanup commands permanently delete Elasticsearch indices, local node state, generated certificates, custom configuration, and logs. Back up snapshots, exported data, or configuration files before removing these paths.

sudo rm -rf /var/lib/elasticsearch
sudo rm -rf /var/log/elasticsearch
sudo rm -rf /etc/elasticsearch

Confirm that the package is no longer installed.

dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' elasticsearch 2>/dev/null | grep '^ii' || echo "elasticsearch package is not installed"

Official Elasticsearch 8 Resources

Conclusion

Elasticsearch 8 is running on Debian from Elastic’s 8.x APT repository as a systemd service with TLS, authentication, version checks, update commands, and a clean removal path. Keep HTTP API access narrow with the Debian UFW firewall guide, and use Elastic’s support matrix before rolling the same procedure into a production cluster.