These scenarios place an already installed Filter in front of an existing application. Install the agents first, as described in Getting started. A request sent directly to the Filter must already return 403.
Each scenario below is inline protection: a permitted request reaches the application only through Filter. A traffic copy, where the visitor stays on the application server, is a separate placement: Traffic copy.
| Placement | When to use it | Page |
|---|---|---|
| Servers | Package installation. Each agent has its own server | Getting started |
| Docker | The same roles as containers on one Docker network | Docker images |
| Kubernetes | The same roles as containers in one namespace | Kubernetes |
| Web application | Filter in front of the Nginx that already serves the site | Web application |
| API | Filter in front of an API gateway | API |
| Reverse proxy | Host selection, the address of the visitor or the API client, WebSocket and gRPC | Configuring Filter as a reverse proxy |
| Load balancer | Visitors are spread across two Filters | Load balancer |
| Kubernetes Ingress | Public Ingress forwards to Filter. Filter routes to the Services | Kubernetes Ingress |
| Legacy application | Filter terminates TLS for an application that answers over HTTP | Legacy application |
| Traffic copy | Visitors stay on the application server while Filter records attacks | Traffic copy |
| Cluster | Settings and the block list stay in sync across sites, including remote data centers | Cluster |
| One MLC, many Filters | One MLC serves several Filters | Point-to-multipoint |
| MLC cluster | Several MLC nodes share the load. Models are built on the master node | Distributed mode |
| API standby | A second PostgreSQL keeps a copy. The standby API serves reads while the primary is down | Fault-tolerant operation of API |
Network ports for these placements are in Access and license. Hardware for each agent is in Introduction.
The Filter proxies to the Nginx that already serves the application. Web application.
The Filter proxies to the API gateway. The gateway keeps routing to the microservices. API.
The load balancer spreads visitors across two Filters. Each Filter proxies to the same application. Load balancer.
DNS points at Ingress. Ingress forwards to Filter. Filter proxies to the Service selected by Host and path. Kubernetes.
The Filter terminates TLS for an application that answers over HTTP. Legacy application.