Run the Elchi Shield sidecar next to Envoy, add its ext_proc HTTP filter ahead of the router, and enable the Coraza engine with the embedded OWASP Core Rule Set in a Shield policy, starting in detect mode and moving to block once the findings are clean.
Keep the blue and green servers in two endpoints resources and switch an EDS cluster's service_name from one to the other with Elchi's cluster endpoints switch, and take a single upstream IP or hostname out of rotation with the endpoint disable API, which serves it to Envoy as DRAINING.
Create a GSLB record for the hostname your Envoy edges serve, add each edge IP with an HTTP, HTTPS or TCP health probe, and let elchi-coredns answer DNS with only the healthy IPs, falling back to a per-record failover name when none are healthy.
Send Envoy's gRPC access logs (ALS v3) to the Elchi collector to build an inventory of every API operation that actually receives traffic, then import your OpenAPI specs to list the operations no spec documents, or export the observed inventory as an OpenAPI document.
Use Elchi as the Envoy control plane - every listener, route, cluster, endpoint and secret is edited in a typed form generated from Envoy's protobuf definitions, validated in the editor and on the server, and pushed to running proxies over xDS without a restart.
Deploy one Elchi control-plane variant per Envoy version so proxies on different versions are served at the same time, then move listeners to the newer version with the listener upgrade, which copies their dependencies to the target version and switches the running Envoy by hot restart.