The path between workloads.

// Why it matters

Applications should not become security infrastructure.

QHx Proxy lets existing services participate in a secure workload communication fabric without embedding identity, tunnel, and notary logic into every application.

• Flowspec-drivenService annotations describe which clients can connect and how the path should be realized.
• Workload-boundTunnels are mutually authenticated against workload identities. A credential without the workload that earned it cannot complete the handshake.
• Protocol-awareApplication-specific intermediation for HTTP, TCP, and MQTT. HTTP semantics are preserved; TCP streams are tunneled transparently; MQTT broker identity is verified before messages are forwarded.
• Notary extensionHTTP flows can request workload-only, logged, or signed request notarization.

// Deployment patterns

Where it runs depends on what you have.

The proxy is the same component in either case. The deployment pattern is what changes.

• SidecarQHx Proxy runs as a sidecar container in the application's pod. Traffic redirects to it via iptables. The application connects to localhost and is otherwise unmodified.
• Direct proxyWhere sidecar injection is not available — bare metal, VMs, constrained Kubernetes — the proxy runs as a node-level daemon and intercepts traffic for co-located workloads.