# Deploying with All-in-One Installer

An **all-in-one installer** is designed for installing Wallarm node as a dynamic module for NGINX in Linux-based environments for [inline traffic filtration](https://docs.wallarm.com/installation/inline/overview.md). This installer automatically identifies your operating system’s and NGINX versions, and install all the necessary dependencies.

The **all-in-one installer** provides a simple node installation process by automatically performing the following actions:

1. Checking your OS and NGINX version.
1. Adding Wallarm repositories for the detected OS and NGINX version.
1. Installing Wallarm packages from these repositories.
1. Connecting the installed Wallarm module to your NGINX.
1. Connecting the filtering node to Wallarm Cloud using the provided token.

## Use cases

Among all supported [Wallarm deployment options](https://docs.wallarm.com/installation/supported-deployment-options.md), this solution is the recommended one for the following **use cases**:

* Your infrastructure is based on bare metal or virtual machines without using container-based methods. Typically, these setups are managed with Infrastructure as Code (IaC) tools like Ansible or SaltStack.
* Your services are built around NGINX. Wallarm can extend its functionalities using the all-in-one installer.

## Requirements

* Access to the account with the **Administrator** role in Wallarm Console for the [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/), or [ME Cloud](https://me1.my.wallarm.com/).
* Supported OS:

    * Debian 10, 11, 12.x, 13.x
    * Ubuntu LTS 18.04, 20.04, 22.04, 24.04
    * Ubuntu non-LTS 24.10, 25.04, 25.10
    * CentOS 7, 8 Stream, 9 Stream, 10 Stream
    * Alma/Rocky Linux 9
    * AlmaLinux 10
    * RHEL 8.x
    * RHEL 9.x
    * RHEL 10.x
    * Oracle Linux 8.x
    * Oracle Linux 9.x
    * Oracle Linux 10.x
    * Redox
    * SuSe Linux
    * Others (the list is constantly widening, contact [Wallarm support team](mailto:support@wallarm.com) to check if your OS is in the list)

* Access to `https://meganode.wallarm.com` to download all-in-one Wallarm installer. Ensure the access is not blocked by a firewall.
* Access to the Wallarm API host for your Cloud: `https://us1.api.wallarm.com`, `https://api.wallarm.com`, or `https://me1.api.wallarm.com`. If access can be configured only via the proxy server, then use the [instructions](https://docs.wallarm.com/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md).
* Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and [API specifications](https://docs.wallarm.com/api-specification-enforcement/overview.md), as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](https://docs.wallarm.com/user-guides/ip-lists/overview.md) countries, regions, or data centers

    **US Cloud:**

    ```
    node-data0.us1.wallarm.com - 34.96.64.17
    node-data1.us1.wallarm.com - 34.110.183.149
    us1.api.wallarm.com - 35.235.66.155
    34.102.90.100
    34.94.156.115
    35.235.115.105
    ```

    **EU Cloud:**

    ```
    node-data1.eu1.wallarm.com - 34.160.38.183
    node-data0.eu1.wallarm.com - 34.144.227.90
    api.wallarm.com - 34.90.110.226
    ```

    **ME Cloud:**

    ```
    node-data0.me1.wallarm.com - 34.166.82.208
    node-data1.me1.wallarm.com - 34.166.82.208
    me1.api.wallarm.com - 34.166.82.208
    ```
* Executing all commands as a superuser (e.g. `root`).
* No system user named `wallarm` exists.
## Step 1: Install NGINX and dependencies

Install the latest NGINX version of:

* **NGINX `stable`** (the latest supported version is v1.30.0) - see how to install it in the NGINX [documentation](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/).
* **NGINX Mainline** (the latest supported version is v1.29.8) - see how to install it in the NGINX [documentation](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/).
* **NGINX Plus** (the latest supported version is NGINX Plus R35) - see how to install it in the NGINX [documentation](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/).
* **Distribution-Provided NGINX** - to install, use the following commands:

    **Debian:**

    ```bash
    sudo apt update 
    sudo apt -y install --no-install-recommends nginx
    ```

    **Ubuntu:**

    ```bash
    sudo apt-get update
    sudo apt-get install nginx
    ```

    **CentOS:**

    ```bash
    sudo yum -y update 
    sudo yum install -y nginx
    ```

    **AlmaLinux, Rocky Linux or Oracle Linux:**

    ```bash
    sudo yum -y update 
    sudo yum install -y nginx
    ```

    **RHEL:**

    ```bash
    sudo yum -y update 
    sudo yum install -y nginx
    ```
## Step 2: Prepare Wallarm token

To install node, you will need a Wallarm token of the [appropriate type](https://docs.wallarm.com/user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation). To prepare a token:

**API token:**


1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens), or [ME Cloud](https://me1.my.wallarm.com/settings/api-tokens).
1. Find or create API token with the `Node deployment/Deployment` usage type.
1. Copy this token.

**Node token:**


1. Open Wallarm Console → **Nodes** in the [US Cloud](https://us1.my.wallarm.com/nodes) or [EU Cloud](https://my.wallarm.com/nodes), or [ME Cloud](https://me1.my.wallarm.com/nodes).
1. Do one of the following: 
    * Create the node of the **Wallarm node** type and copy the generated token.
    * Use existing node group - copy token using node's menu → **Copy token**.
## Step 3: Download all-in-one Wallarm installer

Wallarm suggests all-in-one installations for the following processors:

* x86_64
* ARM64

To download all-in-one Wallarm installation script, execute the command:

**x86_64 version:**

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.x86_64-glibc.sh
```

**ARM64 version:**

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.aarch64-glibc.sh
```
## Step 4: Run all-in-one Wallarm installer

1. Run downloaded script:

    **API token:**

    If using the x86_64 version:

    ```bash
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.x86_64-glibc.sh
    ```

    If using the ARM64 version:

    ```bash
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.aarch64-glibc.sh
    ```        

    The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI).

    **Node token:**

    If using the x86_64 version:

    ```bash
    sudo sh wallarm-6.12.1.x86_64-glibc.sh
    ```

    If using the ARM64 version:

    ```bash
    sudo sh wallarm-6.12.1.aarch64-glibc.sh
    ```

1. Select [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/), or [ME Cloud](https://me1.my.wallarm.com/).
1. Enter Wallarm token.

??? info "ME Cloud: use batch mode"
    For ME Cloud, the Node does not yet support cloud selection via the interactive installer. Use batch mode instead.

    The command for x86_64:

    ```bash
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.x86_64-glibc.sh -- --batch -t <TOKEN> -H me1.api.wallarm.com
    ```

    The command for ARM64:

    ```bash
    sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.aarch64-glibc.sh -- --batch -t <TOKEN> -H me1.api.wallarm.com
    ```
Commands in the further steps are the same for x86_64 and ARM64 installations.

## Step 5: Enable Wallarm node to analyze traffic

By default, the deployed Wallarm Node does not analyze incoming traffic.

To enable traffic analysis and proxying of legitimate traffic, update the [NGINX configuration file](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/), typically located at `/etc/nginx/sites-available/default`.
    
The following minimal configuration adjustments are necessary:

1. Set the Wallarm Node to `wallarm_mode monitoring;`. This mode is recommended for initial deployments and testing.

    Wallarm also supports more modes like blocking and safe blocking, which you can [read more](https://docs.wallarm.com/admin-en/configure-wallarm-mode.md).
1. Determine where the node should forward legitimate traffic by adding the `proxy_pass` directive in the required locations. This could be to the IP of an application server, a load balancer, or a DNS name.
1. If present, remove the `try_files` directive from the modified locations to ensure traffic is directed to Wallarm without local file interference.

```diff
server {
    ...
+   wallarm_mode monitoring;
    location / { 
+        proxy_pass http://example.com;
-        # try_files $uri $uri/ =404;
    }
    ...
}
```

## Step 6: Restart NGINX

Restart NGINX using the following command:

```bash
sudo systemctl restart nginx
```
## Step 7: Configure sending traffic to Wallarm node

Update targets of your load balancer to send traffic to the Wallarm instance. For details, please refer to the documentation on your load balancer.
## Step 8: Test Wallarm node operation

1. Send the request with test [Path Traversal](https://docs.wallarm.com/attacks-vulns-list.md#path-traversal) attack to a protected resource address:

    ```
    curl http://localhost/etc/passwd
    ```

    If traffic is configured to be proxied to `example.com`, include the `-H "Host: example.com"` header in the request.
1. Open Wallarm Console → **Attacks** section in the [US Cloud](https://us1.my.wallarm.com/attacks) or [EU Cloud](https://my.wallarm.com/attacks), or [ME Cloud](https://me1.my.wallarm.com/attacks) and make sure the attack is displayed in the list.

    ![Attacks in the interface](https://docs.wallarm.com/images/admin-guides/test-attacks-quickstart.png)

1. Optionally, [test](https://docs.wallarm.com/admin-en/uat-checklist-en.md) other aspects of the node functioning.
## Step 9: Fine-tune deployed solution

The dynamic Wallarm module with default settings is installed. The filtering node may require some additional configuration after deployment.

Wallarm settings are defined using the [NGINX directives](https://docs.wallarm.com/admin-en/configure-parameters-en.md) or the Wallarm Console UI. Directives should be set in the following files on the machine with the Wallarm node:

* `/etc/nginx/sites-available/default` for the settings on the server and location levels
* `/etc/nginx/nginx.conf` for the settings on the http level
* `/etc/nginx/wallarm-status.conf` with Wallarm node monitoring settings. Detailed description is available within the [link](https://docs.wallarm.com/admin-en/configure-statistics-service.md)

Below there are a few of the typical settings that you can apply if needed:

* [Configuration of the filtration mode](https://docs.wallarm.com/admin-en/configure-wallarm-mode.md)
* [Allocating resources for Wallarm nodes](https://docs.wallarm.com/admin-en/configuration-guides/allocate-resources-for-node.md)
* [Logging Wallarm node variables](https://docs.wallarm.com/admin-en/configure-logging.md)
* [Using the balancer of the proxy server behind the filtering node](https://docs.wallarm.com/admin-en/using-proxy-or-balancer-en.md)
* [Limiting the single request processing time in the directive `wallarm_process_time_limit`](https://docs.wallarm.com/admin-en/configure-parameters-en.md#wallarm_process_time_limit)
* [Limiting the server reply waiting time in the NGINX directive `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout)
* [Limiting the maximum request size in the NGINX directive `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
* [Configuring dynamic DNS resolution in NGINX](https://docs.wallarm.com/admin-en/configure-dynamic-dns-resolution-nginx.md)

## Launch options

As soon as you have the all-in one script downloaded, you can get help on it with:

```
sudo sh ./wallarm-6.12.1.x86_64-glibc.sh -- -h
```

Which returns:

```
...
Usage: setup.sh [options]... [arguments]... [filtering/postanalytics]

OPTION                      DESCRIPTION
-b, --batch                 Batch mode, non-interactive installation.
    --install-only          Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch.
    --skip-ngx-config       Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch.
    --register-only         Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch.
-t, --token TOKEN           Node token, required in a batch mode.
-c, --cloud CLOUD           Wallarm Cloud, one of US/EU/ME, default is EU, only used in a batch mode.
-H, --host HOST             Wallarm API address, for example, api.wallarm.com, us1.api.wallarm.com or me1.api.wallarm.com, only used in a batch mode.
-P, --port PORT             Wallarm API pot, for example, 443.
    --no-ssl                Disable SSL for Wallarm API access.
    --no-verify             Disable SSL certificates verification.
-f, --force                 If there is a node with the same name, create a new instance.
-h, --help
    --version
```

### Batch mode

The `--batch` option triggers **batch (non-interactive)** mode, where the script requires configuration options via the `--token` and `--cloud` flags, along with the `WALLARM_LABELS` environment variable if needed. In this mode, the script does not prompt the user for data input step by step as in the default mode; instead, it requires explicit commands for interaction.

Below are examples of commands to run the script in batch mode for node installation, assuming the script has already been [downloaded](#step-3-download-all-in-one-wallarm-installer):

**US Cloud:**

If using the x86_64 version:

```bash
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.x86_64-glibc.sh -- --batch -t <TOKEN> -c US
```

If using the ARM64 version:

```bash
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.aarch64-glibc.sh -- --batch -t <TOKEN> -c US
```

**EU Cloud:**

If using the x86_64 version:

```bash
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.x86_64-glibc.sh -- --batch -t <TOKEN>
```

If using the ARM64 version:

```bash
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.aarch64-glibc.sh -- --batch -t <TOKEN>
```

**ME Cloud:**

If using the x86_64 version:

```bash
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.x86_64-glibc.sh -- --batch -t <TOKEN> -c ME
```

If using the ARM64 version:

```bash
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-6.12.1.aarch64-glibc.sh -- --batch -t <TOKEN> -c ME
```

### Separate execution of node installation stages

When preparing your own machine image using the all-in-one installer for cloud infrastructure, the standard installation process outlined in this article may not suffice. Instead, you will need to execute specific stages of the all-in-one installer separately to accommodate the requirements of creating and deploying a machine image:

1. Build machine image: At this stage, it is necessary to download binaries, libraries, and configuration files of the filtering node and create a machine image based on them. Utilizing the `--install-only` flag, the script copies the required files and modifies NGINX configurations for node operation. If you wish to make manual adjustments, you can opt to bypass the NGINX file modification by using the `--skip-ngx-config` flag.
1. Initialize a cloud instance with cloud-init: During instance initialization, the bootstrap phase (cloud registration and service start) can be executed using cloud-init scripts. This stage can be run independently from the build phase by applying the `--register-only` flag to the `/opt/wallarm/setup.sh` script copied during the build stage.

This functionality is supported starting from version 4.10.0 of the all-in-one installer in batch mode. The commands below enable the sequential execution of the outlined steps:

**US Cloud:**

If using the x86_64 version:

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.x86_64-glibc.sh
sudo sh wallarm-6.12.1.x86_64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN> -c US
```

If using the ARM64 version:

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.aarch64-glibc.sh
sudo sh wallarm-6.12.1.aarch64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN> -c US
```

**EU Cloud:**

If using the x86_64 version:

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.x86_64-glibc.sh
sudo sh wallarm-6.12.1.x86_64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN>
```

If using the ARM64 version:

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.aarch64-glibc.sh
sudo sh wallarm-6.12.1.aarch64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN>
```

**ME Cloud:**

If using the x86_64 version:

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.x86_64-glibc.sh
sudo sh wallarm-6.12.1.x86_64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN> -c ME
```

If using the ARM64 version:

```bash
curl -O https://meganode.wallarm.com/6.12/wallarm-6.12.1.aarch64-glibc.sh
sudo sh wallarm-6.12.1.aarch64-glibc.sh -- --batch --install-only
sudo env WALLARM_LABELS='group=<GROUP>' /opt/wallarm/setup.sh --batch --register-only -t <TOKEN> -c ME
```
Finally, to complete the installation, you need to [enable Wallarm to analyze traffic](#step-5-enable-wallarm-node-to-analyze-traffic) and [restart NGINX](#step-6-restart-nginx).

### Separate installation of filtering and postanalytics nodes

The filtering/postanalytics switch provides the option to install the postanalytics module [separately](https://docs.wallarm.com/admin-en/installation-postanalytics-en.md). Without this switch, both filtering and postanalytics components are installed together by default.

### API Discovery-only mode

You can use the node in API Discovery-only mode (available since version 5.3.7). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts, and malicious activity from denylisted and graylisted IPs) - are detected and blocked locally (if enabled) but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing](https://docs.wallarm.com/vulnerability-detection/threat-replay-testing/overview.md) does not work. Traffic from whitelisted IPs is allowed.

Meanwhile, [API Discovery](https://docs.wallarm.com/api-discovery/overview.md), [API session tracking](https://docs.wallarm.com/api-sessions/overview.md), and [security vulnerability detection](https://docs.wallarm.com/about-wallarm/detecting-vulnerabilities.md) remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization.

This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking](https://docs.wallarm.com/user-guides/rules/sensitive-data-rule.md) if needed.

To enable API Discovery-only mode:

1. Create or modify the `/etc/wallarm-override/env.list` file:

    ```
    sudo mkdir /etc/wallarm-override
    sudo vim /etc/wallarm-override/env.list
    ```

    Add the following variable:

    ```
    WALLARM_APID_ONLY=true
    ```

1. Follow the [node installation procedure](#requirements).

With the API Discovery-only mode enabled, the `/opt/wallarm/var/log/wallarm/wcli-out.log` log returns the following message:

```json
{"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"}
```

## Starting the installation over

If you need to delete the Wallarm node installation and start again, follow the steps below.

!!! warning "Impact of starting the installation over"
    Starting the installation over involves stopping and deleteing already running Wallarm services, thus pausing traffic filtering until reinstallation. Exercise caution in production or critical traffic environments, as this leaves traffic unfiltered and at risk.

    To upgrade an existing node (e.g., from 4.10 to 5.0), see the [upgrade instructions](https://docs.wallarm.com/updating-migrating/all-in-one.md).

1. Terminate Wallarm processes and remove configuration files:

    ```
    sudo systemctl stop wallarm
    sudo rm -rf /opt/wallarm
    ```
1. Continue with the reinstallation process by following the setup instructions from the [2nd step](#step-2-prepare-wallarm-token).