https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/ This chapter contains configuration guides for setting up and operating Airlock Microgateway in Kubernetes. Hugo en-US https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/gateway-deployment/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/gateway-deployment/ Airlock Microgateway supports the Kubernetes Gateway API. You use Gateway API resources to define a Gateway instance and the reverse proxy specific behavior. In this setup, the Microgateway Operator acts as the Gateway API controller. When you create the CR Gateway, the Operator creates a Deployment and a matching Service that exposes the configured listener ports. You can deploy your Microgateway in one of the following patterns: Ingress: Exposed to clients outside the cluster. In-cluster Gateway: Reachable only from within the cluster. Both patterns use the same Kubernetes Gateway API resources. The main difference is how the Service in front of the Microgateway Engine is exposed. https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/high-availability-and-autoscaling/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/high-availability-and-autoscaling/ By default, a Gateway is deployed with a single replica. However, a single replica is also a single point of failure: any node drain, eviction, or crash can take the Gateway offline. This guide shows how to run Airlock Microgateway with multiple replicas, spread replicas across nodes, protect them during voluntary disruptions, and (optionally) scale automatically under load. Prerequisite A Gateway Deployment. Configuration Run more than one replica Set the replica count in your GatewayParameters. https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/session-handling/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/setup/session-handling/ Session handling lets Airlock Microgateway persist a state across requests by linking a session cookie to a server-side session entry in a session store (Redis or Valkey). This supports concrete filtering use cases such as troubleshooting (correlating request logs) and auditing (reconstructing what a user did within a specific session). Session handling also lays the groundwork for advanced capabilities and authentication scenarios. It enables future features such as a cookie store and global rate limiting, and much more.