diff --git a/src/pages/how-to/routing-peers-and-kubernetes.mdx b/src/pages/how-to/routing-peers-and-kubernetes.mdx
index 45acd601..f6be2b65 100644
--- a/src/pages/how-to/routing-peers-and-kubernetes.mdx
+++ b/src/pages/how-to/routing-peers-and-kubernetes.mdx
@@ -64,7 +64,7 @@ Click on Name & Description to give your policy a name and description. Then cli
 </p>
 
 ### Step 4: Deploy the NetBird agent
-You can deploy the NetBird agent using a daemon set or a deployment. Below is an example of a deployment configuration with 3 replicas.
+You can deploy the NetBird agent using a daemon set or a deployment. Below is an example of a deployment configuration with 1 replica.
 
 ```yaml
 ---
@@ -74,7 +74,7 @@ metadata:
   name: netbird
   namespace: default
 spec:
-  replicas: 3
+  replicas: 1
   selector:
     matchLabels:
       app: netbird
@@ -112,7 +112,25 @@ kubectl apply -f deployment.yml
     In this example the setup key is passed as an environment variable. You should use a secret to pass the setup key.
 </Note>
 
-### Step 5: Verify the deployment
+### Step 5: Make the deployment highly available
+NetBird network routes support multiple routing peers running in a fail-over mode, where one routing peer will be select
+as gateway for a network and when this peer becomes unavailable other routing peer will be select for the role, proving a
+highly available network route.
+
+To make the deployment highly available, you can increase the number of replicas in the deployment configuration to 3 or more.
+
+```yaml
+---
+...
+spec:
+  replicas: 3
+...
+```
+Apply the updated deployment file to your Kubernetes cluster using the following command:
+```shell
+kubectl apply -f deployment.yml
+```
+### Step 6: Verify the deployment
 After deploying the NetBird agent, you can verify that the agent is running by checking the logs of the pods.
 
 ```shell