Skip to main content
This is the page to hand to a platform or infrastructure team before an install. It covers what the platform depends on, what talks to what, and how much capacity to plan for — independent of which model you deploy. For the topology itself, including its diagram and component inventory, go to your model’s guide: Hybrid, External, or Central. Everything ships as a single umbrella Helm chart, neuraltrust-platform, with one value selecting the topology:

Infrastructure dependencies

The chart can run every datastore in-cluster for evaluation. Recommended for production is managed PostgreSQL and Redis (deploy: false plus a host you provide) with ClickHouse left in-cluster. The in-cluster default exists so a proof of concept can helm install without provisioning those services first. Redis is not optional and it is not only a cache: TrustGate uses it for rate limiting and semantic caching on the request path. Redis OSS is sufficient — there is no Enterprise-only feature in use. The chart’s in-cluster Redis runs a plain redis-server.

Ports between components

In-cluster hops are plain Services; there is no service mesh requirement. What has to cross a network boundary depends on the model, and each model page carries its own rules: Hybrid needs outbound HTTPS to NeuralTrust plus one inbound source IP, External needs neither, and Central needs the same outbound set as Hybrid but against your own domain, with the central cluster accepting it.

Capacity

Chart defaults ship as a sensible starting point for evaluation and typical production traffic. They are not a hard ceiling — right-size CPU, memory, replicas, and node pools to match your traffic, latency goals, and budget. The shapes below reflect chart defaults with in-cluster PostgreSQL and Redis and Firewall CPU workers. They do not include the node OS, kube-system, or your ingress controller, so leave headroom for those. Hybrid with fewer products — TrustGate only, so no Firewall — needs substantially less memory. External and Central add the console, ClickHouse, the collector, DataCore, and AlertEngine on top of the data path. Common adjustments: scale out busy gateway and TrustGuard replicas, or enable horizontal autoscaling once your cluster has metrics; right-size Firewall workers if you run a subset of detectors, or move heavy ones to GPU, which needs a separate GPU node pool; pin workloads to a dedicated pool when you want isolation from other cluster tenants.

Datastore sizing floors

Not required

Deployments sometimes budget for these because older material mentioned them, or because comparable products need them. Platform v2 does not:
If you are working from documentation or a diagram that shows Kafka, AISPM, Agent Guardians, or a control-plane Scheduler, it predates chart v2.0.0. The legacy TrustGate/Kafka line ended at v1.14.16.

Where each interface is documented