tutorial-self-managed-install.md

mapped_pages	https://www.elastic.co/guide/en/elastic-stack/current/installing-stack-demo-self.html
navigation_title	Install a self-managed {{stack}}
applies_to	deployment self
products	id elastic-stack id elasticsearch id kibana id elastic-agent id fleet

Install a self-managed {{stack}} [installing-stack-demo-self]

This tutorial demonstrates how to install and configure the latest {{version.stack}} version of the {{stack}} in a self-managed environment. Following these steps sets up a three node {{es}} cluster, with {{kib}}, {{fleet-server}}, and {{agent}}, each on separate hosts. The {{agent}} is configured with the System integration, enabling it to gather local system logs and metrics and deliver them into the {{es}} cluster. Finally, the tutorial shows how to view the system data in {{kib}}.

::::{note} This installation flow relies on the {{es}} automatic security setup, which secures {{es}} by default during the initial installation.

If you plan to use custom certificates (for example, corporate-provided or publicly trusted certificates), or if you need to configure HTTPS for browser-to-{{kib}} communication, you can combine this tutorial with Customize TLS certificates for a self-managed {{stack}}.

For more details, refer to Security overview. ::::

It should take between one and two hours to complete these steps.

• Prerequisites and assumptions
• {{stack}} overview
• Security overview
• Step 1: Set up the first {{es}} node
• Step 2: Configure the first {{es}} node for connectivity
• Step 3: Start {{es}}
• Step 4: Set up a second {{es}} node
• Step 5: Set up additional {{es}} nodes
• Step 6: Consolidate {{es}} configuration
• Step 7: Install {{kib}}
• Step 8: Install {{fleet-server}}
• Step 9: Install {{agent}}
• Step 10: View your system data
• Next steps

Prerequisites and assumptions [install-stack-self-prereqs]

To get started, you need the following:

• A set of virtual or physical hosts on which to install each stack component.
• On each host, a user account with sudo privileges, and curl installed.

The examples in this guide use RPM Package Manager (RPM) packages to install the {{stack}} {{version.stack}} components on hosts running Red Hat Enterprise Linux or a compatible distribution such as Rocky Linux. For instructions on other installation methods, refer to Install {{es}}.

For the full list of supported operating systems and platforms, refer to the Elastic Support Matrix.

The packages needed by this tutorial are:

• elasticsearch-{{version.stack}}-x86_64.rpm
• kibana-{{version.stack}}-x86_64.rpm
• elastic-agent-{{version.stack}}-linux-x86_64.tar.gz

:::{note} For {{agent}} and {{fleet-server}} (both of which use the elastic-agent-{{version.stack}}-linux-x86_64.tar.gz package) we recommend using TAR/ZIP packages over RPM/DEB system packages, since only the former support upgrading using {{fleet}}. :::

Special considerations such as firewalls and proxy servers are not covered here.

For the basic ports and protocols required for the installation to work, refer to the following overview section.

{{stack}} overview [install-stack-self-overview]

Before starting, take a moment to familiarize yourself with the {{stack}} components.

To learn more about the {{stack}} and how each of these components are related, refer to An overview of the {{stack}}.

The examples in this tutorial use the following host addresses:

Component	Example host name	Example IP address
{{es}} node 1	es-node1	203.0.113.21
{{es}} node 2	es-node2	203.0.113.22
{{es}} node 3	es-node3	203.0.113.23
{{kib}}	kibana-host	203.0.113.31
{{fleet-server}}	fleet-server-host	203.0.113.41

These are documentation-only example addresses. Replace them with the values from your environment.

Security overview [security-overview]

This tutorial results in a secure-by-default environment, but not every connection uses the same certificate model. Before you begin, it helps to understand the security layout produced by these steps:

• {{es}} uses the automatic security setup during the initial installation flow. This process generates certificates and enables TLS for both the transport and HTTP layers.
• {{kib}} connects to {{es}} using the enrollment flow from the initial {{es}} setup.
• HTTPS for browser-to-{{kib}} communication is not configured in this tutorial, although it is strongly recommended for production environments. This configuration is covered in Customize TLS certificates for a self-managed {{stack}}.
• {{fleet-server}} is installed using the Quick Start flow, which uses a self-signed certificate for its HTTPS endpoint.
• {{agent}} enrolls using that Quick Start flow, which requires the install command to include the --insecure flag.

::::{note} If you plan to use certificates signed by your organization's certificate authority or by a public CA, complete this tutorial through Step 7 (install {{kib}}), and then continue with the tutorial Customize TLS certificates for a self-managed {{stack}} before installing {{fleet-server}} and {{agent}}. ::::

Step 1: Set up the first {{es}} node [install-stack-self-elasticsearch-first]

To begin, use RPM to install {{es}} on the first host. This initial {{es}} node bootstraps a new cluster. You can find details about all of the following steps in the document Install {{es}} with RPM.

::::{note} For installation steps for other supported methods, refer to Install {{es}}. ::::

1. Log in to the host where you'd like to set up your first {{es}} node.

2. Create a working directory for the installation package:

   mkdir elastic-install-files

3. Navigate to the new directory:

   cd elastic-install-files

4. Download the {{es}} RPM and checksum file from the {{artifact-registry}}:

   curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-{{version.stack}}-x86_64.rpm
   curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-{{version.stack}}-x86_64.rpm.sha512

5. (Optional) Confirm the validity of the downloaded package by checking the SHA of the downloaded RPM against the published checksum:

   sha512sum -c elasticsearch-{{version.stack}}-x86_64.rpm.sha512

   The command should return:

   elasticsearch-{{version.stack}}-x86_64.rpm: OK.

6. (Optional) Import the {{es}} GPG key used to verify the RPM package signature:

   sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

7. Run the {{es}} install command:

   sudo rpm --install elasticsearch-{{version.stack}}-x86_64.rpm

   The {{es}} install process enables certain security features by default, including the following:

   • Authentication and authorization, including the built-in elastic superuser account.
   • TLS certificates and keys for the transport and HTTP layers, stored in /etc/elasticsearch/certs and configured automatically for use by {{es}}.
   • The transport interface is bound to the loopback interface (localhost), preventing other nodes from joining the cluster, while the HTTP interface listens on all network interfaces (http.host: 0.0.0.0).

8. Copy the terminal output from the install command to a local file. In particular, you need the password for the built-in elastic superuser account. The output also contains the commands to enable {{es}} to run as a service, which you use in the next step.

9. Run the following two commands to enable {{es}} to run as a service using systemd. This enables {{es}} to start automatically when the host system reboots. For more details, refer to Running {{es}} with systemd:

   sudo systemctl daemon-reload
   sudo systemctl enable elasticsearch.service

Step 2: Configure the first {{es}} node for connectivity [install-stack-self-elasticsearch-config]

Before moving ahead to configure additional {{es}} nodes, you need to update the {{es}} configuration on this first node so that other hosts are able to connect to it. This is done by updating the settings in the elasticsearch.yml file. For more details about {{es}} configuration and the most common settings, refer to Configure {{es}} and important settings configuration.

1. Obtain your host IP address (for example, by running ifconfig). You need this value later.

2. Open the {{es}} configuration file in a text editor, such as vim:

   sudo vim /etc/elasticsearch/elasticsearch.yml

3. In a multi-node {{es}} cluster, all of the {{es}} nodes must have the same cluster name.

   In the configuration file, uncomment the line #cluster.name: my-application and give the {{es}} cluster any name that you'd like:

   cluster.name: elasticsearch-demo

4. (Optional) Set a node name for this node. If you don't set one, {{es}} uses its host name by default.

   In the configuration file, uncomment the line #node.name: node-1 and give the {{es}} node any name that you'd like:

   node.name: es-node1

   :::{important} If you change node.name on the first {{es}} node, make sure to align its name with the cluster.initial_master_nodes setting, so the cluster can be bootstrapped. :::

5. Configure networking settings.

   1. Uncomment the line #transport.host: 0.0.0.0 to accept connections on all available network interfaces.

      By default, {{es}} listens for transport traffic on localhost, which prevents other {{es}} nodes from joining the cluster. To allow communication between nodes, you need to bind the transport interface to a non-loopback address:

      transport.host: 0.0.0.0 <1>

      1. If you want {{es}} to listen only on a specific interface, set this to the host IP address instead.

   2. Make sure http.host is configured.

      {{es}} should already be configured to listen on all network interfaces for HTTP traffic as part of the automatic setup.

      Verify that this setting is present in your configuration file. If it is not, add it:

      http.host: 0.0.0.0 <1>

      1. If you want {{es}} to listen only on a specific interface, set this to the host IP address instead.

      :::{tip} As an alternative to setting transport.host and http.host separately, you can use network.host to configure both interfaces at once. For details, refer to the {{es}} networking settings documentation. :::

6. Save your changes and close the editor.

   :::{important} After you configure {{es}} to use non-loopback addresses, it enforces bootstrap checks. If {{es}} does not start successfully in the next step, review the Important system configuration documentation. :::

Step 3: Start {{es}} and bootstrap the cluster [install-stack-self-elasticsearch-start]

1. Now, it's time to start the {{es}} service on the first node:

   sudo systemctl start elasticsearch.service

   If you need to, you can stop the service by running sudo systemctl stop elasticsearch.service.

   :::{tip} If {{es}} does not start successfully, check the {{es}} log file at /var/log/elasticsearch/<cluster-name>.log to learn more. For example, if your cluster name is elasticsearch-demo, the log file is /var/log/elasticsearch/elasticsearch-demo.log. :::

2. Make sure that {{es}} is running properly:

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

   In the command, replace $ELASTIC_PASSWORD with the elastic superuser password that you copied from the install command output.

   If all is well, the command returns a response like this:

   {
    "name" : "es-node1",
     "cluster_name" : "elasticsearch-demo",
     "cluster_uuid" : "<cluster-uuid>",
     "version" : {
       "number" : "{{version.stack}}",
       "build_flavor" : "default",
       "build_type" : "rpm",
       ...
     },
     "tagline" : "You Know, for Search"
   }

3. Finally, check the status of {{es}}:

   sudo systemctl status elasticsearch

   As with the previous curl command, the output should confirm that {{es}} started successfully. Type q to exit from the status command results.

Step 4: Set up a second {{es}} node [install-stack-self-elasticsearch-second]

To set up a second {{es}} node, you start by installing the {{es}} RPM package, but then follow a different configuration flow so that the node joins the existing cluster instead of creating a new one. You can find additional details in Reconfigure a node to join an existing cluster.

1. Log in to the host where you'd like to set up your second {{es}} node.

2. Create a working directory for the installation package:

   mkdir elastic-install-files

3. Change into the new directory:

   cd elastic-install-files

4. Download the {{es}} RPM and checksum file:

   curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-{{version.stack}}-x86_64.rpm
   curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-{{version.stack}}-x86_64.rpm.sha512

5. Check the SHA of the downloaded RPM:

   sha512sum -c elasticsearch-{{version.stack}}-x86_64.rpm.sha512

6. (Optional) Import the {{es}} GPG key used to verify the RPM package signature:

   sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

7. Run the {{es}} install command:

   sudo rpm --install elasticsearch-{{version.stack}}-x86_64.rpm

   Unlike the setup for the first {{es}} node, in this case you don't need to copy the output of the install command. By default, the installation prepares the node as a single-node cluster, but in a later step the elasticsearch-reconfigure-node tool updates that configuration so the node can join your existing cluster.

8. Enable {{es}} to run as a service:

   sudo systemctl daemon-reload
   sudo systemctl enable elasticsearch.service

   :::{important} Don't start the {{es}} service yet. Complete the remaining configuration steps first. :::

9. To enable the new {{es}} node to connect to the cluster, create an enrollment token from any node that is already part of the cluster.

   Return to your terminal shell on the first {{es}} node and generate a node enrollment token:

   sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node

10. Copy the generated enrollment token from the command output.

    :::{tip} An enrollment token has a lifespan of 30 minutes. In case the elasticsearch-reconfigure-node command returns an Invalid enrollment token error, try generating a new token.

    Be sure not to confuse an {{es}} enrollment token (for enrolling {{es}} nodes in an existing cluster) with a {{kib}} enrollment token (to enroll your {{kib}} instance with {{es}}, as described in the next section). These two tokens are not interchangeable. :::

11. In the terminal shell for your second {{es}} node, pass the enrollment token as a parameter to the elasticsearch-reconfigure-node tool:

    sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node --enrollment-token <enrollment-token> <1>

    1. Replace <enrollment-token> with the token that you copied in the previous step.

    ::::{note} If elasticsearch-reconfigure-node fails and indicates that the node has already been started or initialized, refer to Cases when security auto-configuration is skipped for a list of possible causes.

    This can happen, for example, if {{es}} was started previously, which creates the data directory and prevents the auto-configuration process from running again. ::::

12. Answer the Do you want to continue with the reconfiguration process prompt with yes (y). The new {{es}} node is reconfigured.

13. Obtain your host IP address (for example, by running ifconfig). You need this value later.

14. Open the new {{es}} node configuration file in a text editor:

    sudo vim /etc/elasticsearch/elasticsearch.yml

    Because of running the elasticsearch-reconfigure-node tool, certain settings have been updated. For example:

    • The transport.host: 0.0.0.0 and http.host: 0.0.0.0 settings are already uncommented.
    • The discovery_seed.hosts setting has the host IP address of the first {{es}} node. As you add each new {{es}} node to the cluster, the discovery_seed.hosts setting contains an array of the IP addresses and port numbers to connect to each {{es}} node that was previously added to the cluster.

15. In the configuration file, uncomment the line #cluster.name: my-application and set it to match the name you specified on the first {{es}} node:

    cluster.name: elasticsearch-demo

16. (Optional) Set a node name for this node. If you don't set one, {{es}} uses its host name by default.

    In the configuration file, uncomment the line #node.name: node-1 and give the {{es}} node any name that you'd like:

    node.name: es-node2

17. (Optional) Review networking settings.

    After running elasticsearch-reconfigure-node, {{es}} is already configured to use non-loopback addresses for transport and HTTP traffic, so no changes are usually required. You can verify this in your configuration file:

    transport.host: 0.0.0.0
    http.host: 0.0.0.0

    ::::{note} If you make changes to the networking settings, ensure that the networking configuration is consistent across all nodes. For example, use the same approach to binding (specific IP addresses or 0.0.0.0) and the same settings (transport.host, http.host, or network.host) across all nodes. For details, refer to the {{es}} networking settings documentation. ::::

18. Save your changes and close the editor.

19. Start {{es}} on the second node:

    sudo systemctl start elasticsearch.service

    :::{tip} If {{es}} does not start successfully, check the {{es}} log file at /var/log/elasticsearch/<cluster-name>.log to learn more. For example, if your cluster name is elasticsearch-demo, the log file is /var/log/elasticsearch/elasticsearch-demo.log. :::

20. (Optional) To monitor the startup and cluster join process of the second {{es}} node, open a new terminal into the node and tail the {{es}} log file:

    sudo tail -f /var/log/elasticsearch/elasticsearch-demo.log <1>

    1. If needed, replace elasticsearch-demo with your cluster name.

    In the log output, you should see entries similar to the following as the node initializes, starts transport, and waits to join the cluster:

    [<es-node2>] Security is enabled
    [<es-node2>] Profiling is enabled
    [<es-node2>] using discovery type [multi-node] and seed hosts providers [settings]
    [<es-node2>] initialized
    [<es-node2>] starting ...
    [<es-node2>] publish_address {<node-ip>:9300}, bound_addresses {[::]:9300}
    [<es-node2>] master not discovered or elected yet ...
    

    After a minute or so, the log should include a message similar to:

    [<es-node2>] master node changed {previous [], current [<es-node1>...]}
    

    Here, es-node2 is the {{es}} node you are starting, and es-node1 represents the node that becomes the elected master. Shortly after that, you should also see:

    [<es-node2>] started {<es-node2>}...
    

    These messages indicate that the second {{es}} node initialized successfully, detected the elected master, and joined the cluster.

21. As a final check, verify that the new node is reachable and responding, and that it appears in the cluster. In the following commands, replace $ELASTIC_PASSWORD with the same elastic superuser password that you used on the first {{es}} node.

    1. To confirm that {{es}} is running properly on the new node, run:

       sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200 <1>

       1. For a more complete check, replace localhost with the IP address of the new node to verify that it is reachable over the network.

       Response example:

       {
           "name" : "es-node2",
           "cluster_name" : "elasticsearch-demo",
           "cluster_uuid" : "<cluster-uuid>",
           "version" : {
           "number" : "{{version.stack}}",
           "build_flavor" : "default",
           "build_type" : "rpm",
           ...
           },
           "tagline" : "You Know, for Search"
       }

    2. To confirm that the node has joined the cluster, run the following command on any {{es}} node:

       sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200/_cat/nodes?v <1>

       1. You can replace localhost with the IP address of any of the nodes.

       The output should include the new node together with the existing node or nodes in the cluster, for example:

       203.0.113.22 46 97 18 0.21 0.23 0.10 cdfhilmrstw - es-node2
       203.0.113.21 31 96  1 0.04 0.03 0.01 cdfhilmrstw * es-node1

Step 5: Set up additional {{es}} nodes [install-stack-self-elasticsearch-third]

To set up additional {{es}} nodes, repeat the process from Step 4: Set up a second {{es}} node for each new node that you add to the cluster. As a recommended best practice, create a new enrollment token for each new node that you add.

For production workloads, you should run at least three {{es}} nodes so the cluster can tolerate the loss of any single node. For guidance, refer to Resilience in small clusters.

Step 6: Consolidate {{es}} configuration [install-stack-self-elasticsearch-consolidate]

Once you have added all your {{es}} nodes to the cluster, you need to consolidate the elasticsearch.yml configuration on all nodes so that they can restart and rejoin the cluster cleanly in the future.

1. On each {{es}} node, open /etc/elasticsearch/elasticsearch.yml in a text editor.

2. Comment out or remove the cluster.initial_master_nodes setting, if it is still present. This setting is only needed while bootstrapping a new cluster.

3. Update discovery.seed_hosts so it includes the IP address and transport port of each master-eligible {{es}} node in the cluster.

   On the first node in the cluster, you need to add the discovery.seed_hosts setting manually. For example, if your cluster has three nodes:

   discovery.seed_hosts:
     - 203.0.113.21:9300
     - 203.0.113.22:9300
     - 203.0.113.23:9300

   ::::{note} If you are not configuring node roles, then all your {{es}} nodes should appear in the discovery.seed_hosts list of all the nodes. ::::

4. Save your changes on each node.

5. Optionally, restart the {{es}} service on each node to validate the updated configuration.

If you do not perform these steps, one or more nodes can fail the discovery configuration bootstrap check when restarted.

For more information, refer to Update the config files and Discovery and cluster formation.

Step 7: Install {{kib}} [install-stack-self-kibana]

As with {{es}}, you can use RPM to install {{kib}} on another host. You can find details about all of the following steps in the document Install {{kib}} with RPM.

::::{note} For installation steps using other supported methods, refer to Install {{kib}}. ::::

Install {{kib}} package

1. Log in to the host where you'd like to install {{kib}} and create a working directory for the installation package:

   mkdir kibana-install-files

2. Change into the new directory:

   cd kibana-install-files

3. Download the {{kib}} RPM and checksum file from the Elastic website:

   curl -L -O https://artifacts.elastic.co/downloads/kibana/kibana-{{version.stack}}-x86_64.rpm
   curl -L -O https://artifacts.elastic.co/downloads/kibana/kibana-{{version.stack}}-x86_64.rpm.sha512

4. Confirm the validity of the downloaded package by checking the SHA of the downloaded RPM against the published checksum:

   sha512sum -c kibana-{{version.stack}}-x86_64.rpm.sha512

   The command should return:

   kibana-{{version.stack}}-x86_64.rpm: OK

5. (Optional) Import the {{es}} GPG key used to verify the RPM package signature:

   sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch <1>

   1. The GPG key used to sign {{kib}} and {{es}} RPM packages is the same.

6. Run the {{kib}} install command:

   sudo rpm --install kibana-{{version.stack}}-x86_64.rpm

7. Run the following two commands to enable {{kib}} to run as a service using systemd, enabling {{kib}} to start automatically when the host system reboots:

   sudo systemctl daemon-reload
   sudo systemctl enable kibana.service

Configure {{kib}}

Before starting the {{kib}} service, update kibana.yml with the following settings:

• The network binding address so that {{kib}} listens on its host IP address.
• A saved objects encryption key required for features such as {{fleet}}.

For more details about {{kib}} configuration, refer to the {{kib}} configuration.

1. Obtain the host IP address for your {{kib}} host (for example, by running ifconfig) and make note of it.

2. Generate a saved objects encryption key on the {{kib}} host:

   sudo /usr/share/kibana/bin/kibana-encryption-keys generate

   The command output includes several encryption-related settings. For this tutorial, copy only the value of xpack.encryptedSavedObjects.encryptionKey, which is required for {{fleet}} features. You can ignore the other generated keys for now.

3. Open the {{kib}} configuration file for editing:

   sudo vim /etc/kibana/kibana.yml

4. Uncomment the line #server.host: localhost and replace the default address with the host IP address that you copied. For example:

   server.host: 203.0.113.31 <1>

   1. If you want {{kib}} to listen on all available network interfaces, you can use 0.0.0.0 instead.

5. Add the xpack.encryptedSavedObjects.encryptionKey setting with the value returned by the kibana-encryption-keys generate command:

   xpack.encryptedSavedObjects.encryptionKey: "min-32-byte-long-strong-encryption-key" <1>

   1. Replace the value with the actual key.

   :::{important} In production environments, consider storing this setting in the {{kib}} keystore instead of kibana.yml. For guidance, refer to {{kib}} secure settings.

   Rotate encryption keys only as part of a planned process. This helps ensure existing encrypted saved objects remain readable. For guidance on rotation, refer to Encryption key rotation. :::

6. Save your changes and close the editor.

{{kib}} is now ready to start and enroll with the {{es}} cluster.

Start and enroll {{kib}}

In this section, you start {{kib}} for the first time and complete enrollment with your {{es}} cluster. This initial startup provides the verification code and enrollment prompt, and it finalizes {{kib}} setup by automatically applying the required connection settings.

1. Start the {{kib}} service:

   sudo systemctl start kibana.service

   If you need to, you can stop the service by running sudo systemctl stop kibana.service.

2. Run the status command to get details about the {{kib}} service:

   sudo systemctl status kibana

3. In the status command output, a URL is shown with:

   • a host address to access {{kib}}
   • a six digit verification code

   For example:

   Kibana has not been configured.
   Go to http://203.0.113.31:5601/?code=<code> to get started. <1>
   

   1. If the URL shows 0.0.0.0, use the host IP address when connecting to {{kib}} in the next step.

   Make note of the verification code.

4. Open a web browser to the external IP address of the {{kib}} host machine, for example: http://203.0.113.31:5601.

   It can take a minute or two for {{kib}} to start up, so refresh the page if you don't see a prompt right away.

   :::{note} The automatic setup used in this tutorial does not configure TLS certificates for browser access to {{kib}}, which is highly recommended for production environments.

   To configure HTTPS for {{kib}}, refer to Encrypt traffic between your browser and {{kib}}. Alternatively, this is also covered in Customize TLS certificates for a self-managed {{stack}}. :::

5. When {{kib}} starts, you're prompted for an enrollment token. You must generate this token in {{es}}:

   1. Return to the terminal session on the first {{es}} node.

   2. Run the elasticsearch-create-enrollment-token command with the -s kibana option to generate a {{kib}} enrollment token:

      sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

   3. Copy the generated enrollment token from the command output and paste it into the enrollment prompt in the browser.

6. Click Configure Elastic.

7. If you're prompted to provide a verification code, copy and paste in the six digit code that was returned by the status command. Then, wait for the setup to complete.

8. When the Welcome to Elastic page appears, sign in with the elastic superuser account and the password that was generated when you installed the first {{es}} node.

9. Click Log in.

{{kib}} is now fully set up and communicating with your {{es}} cluster.

Step 8: Install {{fleet-server}} [install-stack-self-fleet-server]

Now that {{kib}} is up and running, you can install {{fleet-server}}. {{fleet-server}} connects {{agent}} instances to {{fleet}} and serves as a control plane for updating agent policies and collecting agent status information.

::::{note} This tutorial uses the Quick Start installation flow, which generates a self-signed certificate for the {{fleet-server}} by default. For more details about Quick Start and Advanced setup options, refer to Deploy on-premises and self-managed {{fleet-server}}.

If you want to use custom SSL/TLS certificates, continue with Customize TLS certificates for a self-managed {{stack}} instead of continuing with these steps. ::::

Before proceeding, confirm the following prerequisites:

• If you're not using the built-in elastic superuser, ensure your {{kib}} user has All privileges for {{fleet}} and {{integrations}}.
• {{agent}} hosts have direct network connectivity to both the {{fleet-server}} and the {{es}} cluster.
• The {{kib}} host can connect to https://epr.elastic.co on port 443 to download integration packages.

1. Log in to the host where you'd like to set up {{fleet-server}}.

2. Create a working directory for the installation package:

   mkdir fleet-install-files

3. Change into the new directory:

   cd fleet-install-files

4. Obtain the host IP address for your {{fleet-server}} host (for example, by running ifconfig). You need this value later.

5. Return to your web browser. Open the {{kib}} menu and go to Management -> Fleet. {{fleet}} opens with a message that you need to add a {{fleet-server}}.

6. Click Add Fleet Server. The Add a Fleet Server flyout shows up.

7. In the flyout, select the Quick Start tab.

8. Specify a name for your {{fleet-server}} host, for example Fleet Server.

9. Specify the host URL that {{agent}}s need to use to reach the {{fleet-server}}, for example: https://203.0.113.41:8220. This is the {{fleet-server}} host IP address that you copied earlier.

   Be sure to include the port number. Port 8220 is the default used by {{fleet-server}} in an on-premises environment. Refer to Default port assignments in the on-premises {{fleet-server}} install documentation for a list of port assignments.

10. Click Generate Fleet Server policy. A policy is created that contains all of the configuration settings for the {{fleet-server}} instance.

11. On the Install Fleet Server to a centralized host step, for this example we select the Linux tab. Be sure to select the tab that matches both your operating system and architecture (for example, aarch64 or x64). TAR/ZIP packages are recommended over RPM/DEB system packages, since only the former support upgrading {{fleet-server}} using {{fleet}}.

12. Copy the generated commands and then run them one-by-one in the terminal on your {{fleet-server}} host. These commands do the following:

    • Download the {{fleet-server}} package from the {{artifact-registry}}
    • Unpack the package archive
    • Change into the directory containing the install binaries
    • Install {{fleet-server}}

    If you'd like to learn about the install command options, refer to elastic-agent install in the {{agent}} command reference.

13. When prompted, enter Y to install {{agent}} and run it as a service. Wait for the installation to complete.

14. In the {{kib}} Add a Fleet Server flyout, wait for confirmation that {{fleet-server}} has connected.

15. For now, ignore the Continue enrolling Elastic Agent option and close the flyout.

{{fleet-server}} is now fully set up.

Step 9: Install {{agent}} [install-stack-self-elastic-agent]

Next, install {{agent}} on another host and use the System integration to monitor system logs and metrics.

:::{note} You can install only one {{agent}} per host. :::

1. Log in to the host where you'd like to set up {{agent}}.

2. Create a working directory for the installation package:

   mkdir agent-install-files

3. Change into the new directory:

   cd agent-install-files

4. Open {{kib}} and go to Management -> Fleet.

5. On the Agents tab, you should see your new {{fleet-server}} policy running with a healthy status.

6. Open the Settings tab and review the Fleet Server hosts and Outputs URLs. Ensure the URLs and IP addresses are valid for reaching {{fleet-server}} and the {{es}} cluster, and that they use the HTTPS protocol.

7. Reopen the Agents tab and select Add agent. The Add agent flyout shows up.

8. In the flyout, choose a policy name, for example Demo Agent Policy.

9. Leave Collect system logs and metrics enabled. This adds the System integration to the {{agent}} policy.

10. Click Create policy.

11. For the Enroll in Fleet? step, leave Enroll in Fleet selected.

12. On the Install Elastic Agent on your host step, for this example we select the Linux tab. Be sure to select the tab that matches both your operating system and architecture (for example, aarch64 or x64).

    As with {{fleet-server}}, note that TAR/ZIP packages are recommended over RPM/DEB system packages, since only the former support upgrading {{agent}} using {{fleet}}.

13. Copy the generated commands to a text editor. Do not run them yet, because you need to modify one of the commands in the next step.

14. In the sudo ./elastic-agent install command, make two changes:

    • For the --url parameter, check that the port number is set to 8220 (used for on-premises {{fleet-server}}).
    • Append an --insecure flag at the end.

    The --insecure flag is required in this tutorial to allow connections to a {{fleet-server}} endpoint that uses a self-signed certificate. For related guidance, refer to Install Fleet-managed Elastic Agents.

    :::{tip} If you want to set up secure communications using custom SSL certificates, refer to Customize TLS certificates for a self-managed {{stack}}. :::

    The result should look like the following:

    sudo ./elastic-agent install --url=https://203.0.113.41:8220 --enrollment-token=VWCobFhKd0JuUnppVYQxX0VKV5E6UmU3BGk0ck9RM2HzbWEmcS4Bc1YUUM== --insecure

15. Run the commands one-by-one in the terminal on your {{agent}} host. The commands do the following:

    • Download the {{agent}} package from the {{artifact-registry}}.
    • Unpack the package archive.
    • Change into the directory containing the install binaries.
    • Install {{agent}}.

16. When prompted, enter Y to install {{agent}} and run it as a service. Wait for the installation to complete:

    Elastic Agent has been successfully installed.
    

17. In the {{kib}} Add agent flyout, wait for confirmation that {{agent}} has connected.

18. Close the flyout.

Your new {{agent}} is now installed and enrolled with {{fleet-server}}.

Step 10: View your system data [install-stack-self-view-data]

Now that all components are installed, you can view your data in multiple ways. Elastic {{observability}} provides solution views for exploring host activity, and each integration can also provide dedicated dashboards and visualizations. In this tutorial, you'll first check the host view in {{observability}}, then open example logs and metrics dashboards from the System integration.

The System integration assets (including dashboards) are installed automatically when you add the System integration to the {{agent}} policy.

View your host data in {{observability}}:

1. Open the {{kib}} menu and go to Observability -> Infrastructure -> Hosts.
2. Confirm that your host appears and is reporting data.

View your system log data:

1. Open the {{kib}} menu and go to Analytics -> Dashboard.
2. In the query field, search for Logs System.
3. Select the [Logs System] Syslog dashboard link. The {{kib}} Dashboard opens with visualizations of Syslog events, hostnames and processes, and more.

View your system metrics data:

1. Open the {{kib}} menu and return to Analytics -> Dashboard.
2. In the query field, search for Metrics System.
3. Select the [Metrics System] Host overview link. The {{kib}} Dashboard opens with visualizations of host metrics including CPU usage, memory usage, running processes, and others.

You've successfully set up a three-node {{es}} cluster, with {{kib}}, {{fleet-server}}, and {{agent}}.

Next steps [install-stack-self-next-steps]

Now that you've successfully configured an on-premises {{stack}}, you can learn how to customize the certificate configuration for the {{stack}} in a production environment using trusted CA-signed certificates. Refer to Customize TLS certificates for a self-managed {{stack}} to learn more.

You can also start using your newly set up {{stack}} right away:

• Do you have data ready to ingest? Learn how to bring your data to Elastic.
• Use Elastic {{observability}} to unify your logs, infrastructure metrics, uptime, and application performance data.
• Want to protect your endpoints from security threats? Try {{elastic-sec}}. Adding endpoint protection is just another integration that you add to the agent policy!