--- title: Voidhawk Deployment | Kubernetes or Hosted Edge | ZioSec description: Compare processing boundaries, attachment modes, signal, enforcement, and operations for Voidhawk. url: https://ziosec.com/voidhawk/deployment --- # Voidhawk deployment Choose the boundary, then choose the signal. Voidhawk is in active development; deployment is scoped with design partners. [Back to Voidhawk](/voidhawk) | [Plan a design partnership](/contact?intent=voidhawk) ## Two processing boundaries **Self-hosted:** a Helm chart installs Voidhawk in one namespace in your Kubernetes cluster. Request data and application-specific calibration stay in your infrastructure. **Hosted edge:** ZioSec operates the edge. Traffic is processed in ZioSec infrastructure before being forwarded to your origin. ## Self-hosted Kubernetes: what installs Requires Kubernetes 1.27+ and GPU capacity for inference. Nothing serves traffic until an Ingress or HTTPRoute names Voidhawk. - **Controller x1:** read-only cluster access; builds a cached routing table from Ingresses and Services. Listed allocation: 50m CPU / 64Mi memory. - **Proxy x2:** the data plane inspects and forwards. It holds no Kubernetes API credential and retains cached routing through controller restarts. Listed allocation: 100m CPU / 128Mi memory each. - **Inference nodes x1+:** calibrate fields and adjudicate ambiguous cases. Each node exclusively holds one GPU. Use two or more inference nodes where that tier must survive a node loss. - Also installs the Voidhawk IngressClass, policy and list CRDs, a read-only ClusterRole, and a policy admission webhook. - Optional: customer PostgreSQL for durable history, and an ASN/country file for those rule dimensions. ## Compare attachment modes | Capability | ext_proc | Mirrored | TLS passthrough | | --- | --- | --- | --- | | Attachment | gRPC processor in request and response phases | Duplicate requests; gateway does not wait | SNI routing; Voidhawk terminates TLS | | Gateway fit | Envoy family | Any gateway that can mirror | Traefik, HAProxy, NGINX Ingress, F5 | | Request signal | Yes | Yes | Yes | | Response signal | Yes | No | Yes | | Can refuse a request | Yes, or run rules in dry-run | No; observe-only | Yes | | Response-based detection | Login outcomes, reflection, leakage | Unavailable | Login outcomes, reflection, leakage | | TLS fingerprint | Gateway forwards it | If gateway can supply one | Voidhawk computes JA3/JA4 | | Layer 7 routing | Your gateway retains it | Your gateway retains it | Voidhawk owns it for selected hosts | | Scope | Per route | Mirrored traffic | Per hostname | ### ext_proc: recommended for the Envoy family Your gateway terminates TLS and retains routing, path rewrites, header manipulation, and redirects. It calls Voidhawk in both request and response phases. Supported families in this deployment include Envoy Gateway, Istio, Contour, Gloo, kgateway, and raw Envoy. Attach per route. Forward the client address and JA4 fingerprint as X-Ja4 or through gateway metadata. Voidhawk can inspect headers and bodies, refuse requests, apply mutations, inspect responses for reflection and leakage, and read login outcomes. For full signal without blocking, put every rule in dry-run. ### Mirroring: a request traffic study Your gateway duplicates requests to Voidhawk and does not wait. The production path stays unchanged. Provide a mirror destination, client address, and a fingerprint if the gateway can supply one. Voidhawk scores and records requests and calibrates against your application's request traffic. It cannot refuse traffic. It sees no responses, so there are no login outcomes, credential-stuffing or enumeration detection, response reflection confirmation, or leak detection. Use when a synchronous processor cannot be added yet. For response signal without blocking, prefer ext_proc dry-run where supported. ### TLS passthrough: Voidhawk owns L7 for selected hostnames An L4 gateway routes by SNI without decrypting. Voidhawk terminates TLS, sees the ClientHello, and computes JA3/JA4. Supply SNI routing and certificates for delegated hostnames. Layer 7 responsibility moves to Voidhawk for those hosts. This fits Traefik, HAProxy, NGINX Ingress, and F5 deployments where the gateway cannot forward the needed fingerprint. The mode sees requests, responses, bidirectional WebSocket frames, and gRPC over HTTP/2, and can enforce decisions. ## Hosted edge 1. Point the CDN origin path to the Voidhawk edge. 2. Forward the client address and a JA4 fingerprint header. 3. Configure the origin to accept only Voidhawk egress ranges. 4. Voidhawk inspects, decides, and forwards allowed traffic. Requests and responses are processed in ZioSec infrastructure. The edge can refuse requests. Nothing installs in the customer's cluster; updates are applied by ZioSec. ## Day two: updates and records Self-hosted installations pull model weights and analyzer improvements as signed OCI artifacts, directly or through a customer-controlled registry. Artifacts are verified before use. ZioSec does not initiate inbound connections into the cluster. Per-endpoint calibration is fitted locally and stays there. The customer sources the ASN/country file; it is read at startup, so refreshing it requires a restart. One structured verdict per request records decision, attack class, reason, confidence, endpoint, field, and available identity and cohort context. Access through JSON stdout logs, the query API, or optional PostgreSQL with retention and rollup. Kubernetes policy and lists are CRDs and can be managed with existing Kubernetes/GitOps workflows. [Plan your deployment](/contact?intent=voidhawk)