This guide deploys Mikiri WAF and places one site on it. The single path from install to a protected site is Deploy your first protected application. The short checklist is Quick start. The pages below are the full sequence. The agent packages, every configuration option and the API methods are described on their own pages.
Each agent runs on its own server. The hardware for each server is in Clustering and fault tolerance.
Deploy your first protected application places API, WMC and PostgreSQL on one server, with Filter and MLC on their own servers.
Docker can place these roles in containers on a shared network. The image steps are in Docker images. The order of work on this page stays the same.
The agents behind the Filter are the same in both placements. The difference is whether the visitor's request passes through Filter.
| Inline | Traffic copy | |
|---|---|---|
| Where the visitor connects | Filter, which proxies a permitted request to the application | The application server. That server sends a duplicate of the request to the Filter |
| What the visitor receives | The Filter's block page, or the application's response | The application's response |
| When to use it | The Filter must be able to stop a request | The current request path stays in place while Mikiri WAF records attacks |
| Closest familiar name | IPS | IDS |
Use one placement per site. One Filter can serve an inline site and a copied site at the same time: each site has its own virtual host.
The steps for each placement:
Where the Filter sits relative to Nginx, an API gateway, a load balancer, Kubernetes Ingress, or a legacy application is in Deployment scenarios.