How to Install the Elastic Stack (Elasticsearch, Logstash, and Kibana)

Install the Elastic Stack in dependency order: Elasticsearch first, Kibana second, and Logstash third. Use one supported Elastic release across every component. Docker is the simplest route for a local evaluation, DEB or RPM packages fit Linux hosts managed with systemd, and Docker Compose is suited to repeatable multi-node deployments.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

Before exposing anything beyond a test machine, decide how certificates, credentials, network access, backups, and upgrades will be managed. The official local-start workflow keeps the stack on localhost and creates initial credentials, but that safe evaluation default is not a production network design.

#	Preview	Product	Price
1		Elasticsearch in Action	$41.13	Buy on Amazon
2		Elasticsearch: The Definitive Guide: A Distributed Real-Time Search and Analytics Engine	$24.02	Buy on Amazon
3		Elasticsearch in Action, Second Edition	$45.62	Buy on Amazon
4		ElasticSearch Cookbook	$63.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Choose an installation method

The right method depends on whether you are testing the stack, integrating it with a Linux host, or describing a repeatable cluster as configuration. All three approaches install the same products, but they differ in service management, networking, secrets, and upgrade work.

For a first look at Elasticsearch and Kibana, start with Docker. Choose DEB on Debian or Ubuntu-family systems and RPM on Red Hat, CentOS, SLES, OpenSUSE, and other RPM-based systems when host-level logging and systemd matter. Use Compose when several nodes must be created consistently from a version-controlled definition.

#1 Best Overall

Sale

Elasticsearch in Action

$41.13

Buy on Amazon

Plan the installation before running it

Select and pin one supported release

Choose a currently supported Elastic release at the time you install. Use that same release for Elasticsearch, Kibana, Logstash, and any Beats, Elastic Agent, APM Server, or other Elastic component you add. Do not mix arbitrary major or minor versions. Kibana should match Elasticsearch down to the patch version whenever possible.

Record the selected version in the package names, image tags, Compose file, and deployment notes. Pinning prevents one machine from silently receiving a different build and makes rollback or rebuilds understandable.

Decide whether this is a trial or a service

A local trial can keep everything on one machine and bind access to localhost. A service installation needs decisions about hostnames, trusted networks, firewall rules, persistent storage, service accounts, log retention, and how clients will authenticate. A multi-node design also needs explicit cluster discovery and node roles; do not treat a single-node trial as a production topology.

Plan certificates before enrolling agents

Decide which certificate authority and server certificates clients will trust before deploying Fleet-managed Elastic Agents or other production shippers. Changing certificates later can require those agents to be reinstalled. This makes certificate planning an installation prerequisite rather than a finishing task.

Protect generated values

Passwords, API keys, private keys, and the local-start .env file are secrets. Set restrictive file permissions, keep secrets out of source control, and distribute credentials through your normal secret-management process. Never paste generated credentials into a public issue, image, Compose file, or shell history that other users can read.

Install Elasticsearch first

Elasticsearch is the dependency that Kibana connects to and that Logstash writes to. Install and start it before either of the other core products.

Option A: Docker local-start workflow

Elastic maintains a Docker-based local-start workflow for trying the stack on a personal machine. It creates a Docker-based Elasticsearch and Kibana setup, generates a random password for the elastic user, writes local values to .env, and keeps access on localhost by default.

1. Install a supported Docker engine and confirm that your account can run containers.
2. Obtain the maintained local-start project and select the same supported release you intend to use for any later Logstash or agent installation.
3. Run the project’s startup procedure. Let it generate the password and certificates instead of replacing them with ad-hoc values.
4. Read the generated local values from .env, protect that file, and record the Elasticsearch endpoint, username, password, and certificate information in a secure location.
5. Confirm that the Elasticsearch container is running and that its health endpoint responds from the local machine before proceeding to Kibana verification.

This workflow is deliberately convenient for evaluation. Because its default binding is localhost, another computer will not be able to connect until you intentionally redesign the network exposure and TLS arrangement.

Rank #2

Sale

Elasticsearch: The Definitive Guide: A Distributed Real-Time Search and Analytics Engine

$24.02

Buy on Amazon

Option B: DEB package on Debian or Ubuntu

1. Configure the official package source or obtain the DEB file for the exact release selected in your version plan.
2. Install the package with the distribution package manager. The package creates the conventional Elasticsearch service and configuration locations for the host.
3. Review the generated security and network configuration before starting the service. Set the endpoint, certificates, and credentials required by your topology rather than copying settings from an unrelated version.
4. Enable and start the service with systemd, for example sudo systemctl enable --now elasticsearch, then inspect systemctl status elasticsearch and the service logs for startup errors.
5. Record the endpoint and all generated or administrator-supplied credentials and certificates. You will need them when configuring Kibana and Logstash.

Option C: RPM package on Red Hat-family and other RPM systems

1. Configure the appropriate RPM repository or obtain the RPM file for the same selected release.
2. Install it with the system’s package manager, such as the distribution’s dnf or yum workflow.
3. Review security, storage, and network settings, then enable and start the Elasticsearch systemd service.
4. Check service status and logs before installing dependants. A clean process start is not sufficient if the node cannot authenticate, bind its address, or initialize its data path.
5. Save the endpoint, certificates, and credentials in your protected deployment record.

Elasticsearch checks before continuing

• The service or container remains running after startup.
• The HTTP endpoint is reachable from the machine where Kibana will run.
• The credentials you recorded authenticate successfully.
• The certificate presented by Elasticsearch is trusted by the client that will run Kibana.
• Firewall rules expose only the interfaces required by your design.

Install and connect Kibana

Install Kibana after Elasticsearch and use the identical supported version. Kibana must be able to reach and authenticate to the Elasticsearch endpoint before you add an ingestion service.

Package installation

1. Install the matching Kibana DEB or RPM package on the host where Kibana will run.
2. Set Kibana’s Elasticsearch connection details to the endpoint, credentials, and certificate authority selected for your Elasticsearch installation.
3. Choose the listener address deliberately. A local evaluation can remain on localhost; a shared deployment requires an approved interface, firewall rule, and TLS design.
4. Enable and start the Kibana systemd service, then inspect its status and logs.
5. Open the Kibana interface from an approved client and authenticate with the credentials created or configured during Elasticsearch setup.

Docker or Compose installation

Use the official Kibana image with the same pinned release as Elasticsearch. In a Compose deployment, define Kibana’s dependency on the Elasticsearch service, connection settings, certificate trust, persistent configuration, and published interfaces in the Compose file. Start Elasticsearch first when bringing up the stack, then start Kibana and verify that it reports a connected backend.

What a successful Kibana connection proves

A successful login proves that Kibana can resolve the endpoint, establish the network connection, validate the certificate, and authenticate. It does not prove that Logstash pipelines, data views, agent enrollment, retention, or production firewall rules are correct; those require separate checks.

Install and configure Logstash third

Logstash is the ingestion and transformation layer. Install the matching release only after Elasticsearch and Kibana are working.

Install it as a Linux service

1. Install the Logstash DEB or RPM package for the same release used by Elasticsearch and Kibana.
2. Create at least one pipeline with an input, any required filters, and an Elasticsearch output. The input determines how events arrive; filters parse or enrich them; the output sends the resulting events to Elasticsearch.
3. Set the output endpoint, credentials, and certificate trust to the values used by your Elasticsearch deployment.
4. Validate the pipeline configuration before starting the service. Correct syntax cannot compensate for an unreachable endpoint or invalid credentials.
5. Start Logstash as a systemd service and monitor its service output while sending a small test event.

Run it in Docker

Use the official Logstash image at the pinned release. Mount the pipeline configuration and any certificate material into the container using read-only paths where practical. In Compose, define the Logstash service after Elasticsearch and Kibana, supply secrets without committing them to the project, and persist only the data and logs your operating model requires.

Design the first pipeline narrowly

Begin with one known input and one Elasticsearch output. Add parsing filters only after the raw event reaches the destination. This isolates connectivity, authentication, mapping, and parsing failures instead of making a large pipeline impossible to diagnose.

Add agents, Beats, APM, or Hadoop only when required

Elastic’s self-managed installation order places Elastic Agent or Beats, APM Server, and Elasticsearch Hadoop after the three core products. Do not install every integration by default.

Elastic Agent and Fleet

Deploy Fleet-managed agents only after the production certificate authority, server certificates, enrollment policy, and network paths are stable. A later certificate replacement can force agents to be reinstalled, so postponing enrollment until that design is final avoids unnecessary churn.

Rank #3

Sale

Elasticsearch in Action, Second Edition

$45.62

Buy on Amazon

Beats

Add a Beat when its collection model fits the data source and you have decided whether it sends directly to Elasticsearch or through Logstash. Keep its version aligned with the rest of the stack and test a single event before broad rollout.

APM Server

Add APM only when application tracing is part of the requirement. Configure its output and TLS trust against the already verified Elasticsearch or ingestion path, then test one instrumented service before enrolling an entire environment.

Elasticsearch Hadoop

Use the Hadoop integration only for a workload that needs it. It is not a prerequisite for ordinary Elasticsearch, Kibana, and Logstash operation.

Validate the complete data path

Validation should follow an event from its source to a visible Kibana data view rather than stopping at “all services are running.”

1. Confirm that Elasticsearch, Kibana, and Logstash are running at their intended versions.
2. From the Logstash host or container, verify DNS or host resolution, routing, certificate trust, and authentication to Elasticsearch.
3. Send one small, identifiable test event through the configured Logstash input.
4. Watch the Logstash service output for input, filter, authentication, mapping, or output errors.
5. Check Elasticsearch for the target index or data stream and confirm that the event arrived with the expected timestamp and fields.
6. In Kibana, create or select the corresponding data view and search for the unique marker in the test event.
7. Remove the test record only if your retention or data-quality procedure requires it; otherwise retain it as an installation check.

If the event is visible in Kibana, the core path is functioning. Continue with representative events, failure handling, access controls, and monitoring before calling the deployment production-ready.

Security and network hardening

Keep the initial exposure private

The local-start workflow exposes the stack through localhost. Preserve that restriction while evaluating it. For a shared or production deployment, publish only the interfaces required by clients and cluster communication, then enforce firewall rules and authenticated TLS connections. The exact ports and firewall rules depend on whether the products share a host, run in containers, or span multiple nodes.

Use trusted certificates

Certificates must cover the hostnames clients actually use and be signed by a authority those clients trust. Distribute the CA securely, verify certificate chains from every client type, and complete this work before Fleet or Agent enrollment.

Handle passwords and API keys as credentials

Rotate credentials according to your security policy, restrict access to generated files, and avoid putting secrets in Compose files, shell commands, tickets, or source repositories. If a secret leaks, replace it and update every dependent service rather than merely hiding the old value.

Rank #4

ElasticSearch Cookbook

$63.99

Buy on Amazon

Separate evaluation from production

A local single-node stack is useful for learning and pipeline development. Production requires deliberate storage, availability, backups, access control, certificate lifecycle, upgrade testing, and monitoring decisions that are outside the local-start defaults.

Upgrade and maintenance strategy

Keep the stack version-aligned during upgrades. Pin package versions and container image tags in repeatable deployments, document the target release, and upgrade Elasticsearch, Kibana, Logstash, and attached components according to Elastic’s compatibility guidance.

• Test the upgrade against a representative pipeline and dashboard set before changing production.
• Back up the configuration, certificates, saved objects, and any data required by your recovery plan.
• Upgrade the components in a controlled sequence rather than allowing one package or image to drift ahead silently.
• Recheck authentication, certificate trust, Logstash outputs, data views, and agent enrollment after the change.
• Keep a rollback plan that matches the storage and index compatibility limits of the selected release.

Troubleshooting by symptom

Elasticsearch starts, then stops

Inspect the service or container logs first. Check the configured data path, permissions, certificate files, address binding, and version-specific security settings. A repeated restart loop usually indicates a configuration or filesystem problem rather than a Kibana issue.

Kibana cannot connect to Elasticsearch

Verify the endpoint that Kibana uses, name resolution, firewall policy, certificate authority, server-name matching, username, and password. Test from the Kibana host, not only from the Elasticsearch host. If Elasticsearch is bound to localhost, a Kibana process on another machine cannot reach it until the network design changes.

Logstash is running but no events arrive

Check the input listener or source connection, then inspect pipeline logs for parsing and output errors. Confirm that the output points to the intended Elasticsearch endpoint and that its credentials and certificate trust are valid. A running process with an empty input is not evidence that ingestion works.

Events arrive with unexpected fields or mappings

Send one raw event, inspect the filter stages, and compare the resulting field names and types with the destination index or data stream mapping. Add transformations incrementally so the stage that changes the event remains identifiable.

Agents fail after a certificate change

Review the agent’s trusted CA and enrollment state. If the server certificate or issuing authority changed after production enrollment, follow the reinstallation and reenrollment procedure required by your management setup instead of repeatedly retrying with stale trust material.

A local deployment is unexpectedly reachable from other machines

Inspect container port publishing, host listener addresses, firewall rules, and any reverse proxy in front of Kibana or Elasticsearch. Restore localhost-only exposure for a trial or apply an intentional TLS and access-control design before allowing remote clients.

Quick Recap

SaleBestseller No. 1

Elasticsearch in Action

$41.13

SaleBestseller No. 2

Elasticsearch: The Definitive Guide: A Distributed Real-Time Search and Analytics Engine

$24.02

SaleBestseller No. 3

Elasticsearch in Action, Second Edition

$45.62

Bestseller No. 4

ElasticSearch Cookbook

$63.99

Recommended decision path

1. For a personal evaluation, use the maintained Docker local-start workflow and leave its localhost binding intact.
2. For a Linux host that must behave like a native service, install matching DEB or RPM packages and manage them with systemd.
3. For repeatable multi-node environments, encode pinned images, networks, storage, certificates, and secrets in Docker Compose.
4. Regardless of method, install Elasticsearch, then Kibana, then Logstash; validate each dependency before adding the next.
5. Add agents, Beats, APM, or Hadoop only when a defined workload needs them, and complete certificate planning before production enrollment.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.