# Upgrading NGINX Ingress controller with integrated Wallarm modules These instructions describe the steps to upgrade deployed Wallarm NGINX-based Ingress Controller to the latest 6.x. To upgrade the end‑of‑life node (3.6 or lower), please use the [different instructions](https://docs.wallarm.com/updating-migrating/older-versions/ingress-controller.md). !!! warning The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](https://docs.wallarm.com/updating-migrating/nginx-ingress-retirement.md) An [Envoy/Istio-based connector](https://docs.wallarm.com/installation/connectors/istio.md) is also available today for environments already using Envoy. ## Requirements * Kubernetes platform version 1.31-1.35 * [Helm](https://helm.sh/) package manager * Compatibility of your services with the [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) version 1.15.0 * 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/) * Access to the Wallarm API host for your Cloud: `https://us1.api.wallarm.com`, `https://api.wallarm.com`, or `https://me1.api.wallarm.com` * Access to `https://charts.wallarm.com` to add the Wallarm Helm charts. Ensure the access is not blocked by a firewall * Access to the Wallarm repositories on Docker Hub `https://hub.docker.com/r/wallarm`. Make sure the access is not blocked by a firewall * 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 ``` ## Step 1: Update the Wallarm Helm chart repository ```bash helm repo update wallarm ``` ## Step 2: Check out all coming K8s manifest changes To avoid unexpectedly changed Ingress controller behavior, check out all coming K8s manifest changes using [Helm Diff Plugin](https://github.com/databus23/helm-diff). This plugin outputs the difference between the K8s manifests of the deployed Ingress controller version and of the new one. To install and run the plugin: 1. Install the plugin: ```bash helm plugin install https://github.com/databus23/helm-diff ``` 2. Run the plugin: ```bash helm diff upgrade -n wallarm/wallarm-ingress --version 6.12.2 -f ``` * ``: the name of the Helm release with the Ingress controller chart. * ``: the namespace the Ingress controller is deployed to. * ``: the path to the `values.yaml` file with Ingress Controller 6.x settings. You can reuse the previous version's file, updating it [for the Tarantool-to-wstore transition](https://docs.wallarm.com/updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics). Helm values renamed: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. Apply this change in `values.yaml` if postanalytics memory is explicitly [allocated](https://docs.wallarm.com/admin-en/configuration-guides/allocate-resources-for-node.md). 3. Make sure that no changes can affect the stability of the running services and carefully examine the errors from stdout. If stdout is empty, make sure that the `values.yaml` file is valid. ## Step 3: Upgrade the Ingress controller !!! info "" It is recommended to first upgrade the NGINX Ingress Controller in a staging Kubernetes environment to validate the changes before deploying to production. Upgrade the deployed NGINX Ingress controller: ``` bash helm upgrade -n wallarm/wallarm-ingress --version 6.12.2 -f ``` * ``: the name of the Helm release with the Ingress controller chart * ``: the namespace the Ingress controller is deployed to * ``: the path to the `values.yaml` file with Ingress Controller 6.x settings. You can reuse the previous version's file, updating it [for the Tarantool-to-wstore transition](https://docs.wallarm.com/updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics): Helm values renamed: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. Apply this change in `values.yaml` if postanalytics memory is explicitly [allocated](https://docs.wallarm.com/admin-en/configuration-guides/allocate-resources-for-node.md). ## Step 4: Test the upgraded Ingress controller 1. Make sure the version of the Helm chart was upgraded: ```bash helm list -n ``` Where `` is the namespace the Helm chart with the Ingress controller is deployed to. The chart version should correspond to `wallarm-ingress-6.12.2`. 1. Get the Wallarm pod: ``` bash kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress ``` The pod status should be **STATUS: Running** and **READY: N/N**: ``` NAME READY STATUS RESTARTS AGE ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s ``` If upgrading from the version 5.x or lower, you will notice that there is no separate Tarantool pod anymore, wstore runs within the main `-wallarm-ingress-controller-xxx` pod. 1. Send the request with the test [Path Traversal](https://docs.wallarm.com/attacks-vulns-list.md#path-traversal) attack to the Wallarm Ingress controller address: ```bash curl http:///etc/passwd ``` Check that the solution of the newer version processes the malicious request as it did in the previous version. Once the upgrade is successfully validated in the staging environment, proceed with upgrading the production environment.