Platforms

One engine. The topologies you already have.

xorappsec ships as a machine-learning reverse-proxy attachment (the xorappsec binary / container). ML runs in that process. It is first-class on Linux, Docker, and Kubernetes. It does not compile into NGINX or Kong today — it sits in front of the origin, or one hop behind an edge that already terminates TLS. List that edge in trusted-proxies.

xorappsec as a security plane in front of a cluster
In Kubernetes, run xorappsec as a Deployment in front of the Service you already expose.

Kubernetes

Helm chart and raw manifests live in the xorappsec-deploy repository. Typical shape: Deployment (2+ replicas), ClusterIP Service, ConfigMap for policy, Secret for the management token, optional HPA / Ingress / PVC.

helm install xorappsec ./helm/xorappsec \
  --set upstream=http://my-app:80 \
  --set mgmtToken="$XORAPPSEC_MGMT_TOKEN" \
  --set failOpen=false

Persist data-dir with a PVC or learning resets on every reschedule. Do not put port 9090 on the Ingress. Step-by-step: Kubernetes tutorial.

Helm

Values map to XORAPPSEC_* env vars. Changing policy: checksums the pod spec so a GitOps policy edit rolls replicas.

Docker

Playground: docker compose up --build in the engine repo. Production-shaped compose is in xorappsec-deploy (token, healthchecks, read-only root, private management).

docker build -t xorappsec:1.0.0 .
docker run --read-only --user 65532:65532 -p 8080:8080 xorappsec:1.0.0

Linux / systemd

Install the binary to /usr/local/bin, config to /etc/xorappsec, data to /var/lib/xorappsec. The unit runs doctor then all. ExecReload is SIGHUP (policy only).

NGINX

Two honest topologies:

  1. xorappsec terminates HTTP(S) and proxies to the origin. NGINX is unused on the data path, or only serves static files on another name.
  2. NGINX (or Ingress-NGINX) is the edge. It terminates TLS and proxy_passes to xorappsec. Set trusted-proxies to the NGINX CIDR so X-Forwarded-For is the real client. xorappsec then proxies to the app Service.

There is no xorappsec NGINX dynamic module in 1.0. Tutorial: NGINX, Kong, Envoy.

Kong

Same hop model: Kong (or Kong Ingress) as the edge, xorappsec as the next upstream, origin behind xorappsec. Use a Kong service/route that targets the xorappsec Service. Identity headers Kong injects can be listed as source-identifiers if you rate-limit on a consumer key rather than IP.

There is no Kong plugin that embeds the inspect crate. The engine stays its own process so you can upgrade Kong and xorappsec independently.

Envoy, Envoy Gateway, Istio

Terminate at the gateway, cluster route to xorappsec, then to the workload. Honour x-forwarded-for only from the gateway CIDR. For Istio, a sidecar is not required; treat xorappsec as an in-mesh HTTP service or as the ingress gateway’s only backend for public hosts.

What 1.0 does not ship

Native NGINX/Kong/Envoy modules (in-process inspect). Those are extension points in Architecture.md. Until they exist, the reverse-proxy hop is the supported, tested attachment.

Tutorials Production