> ## Documentation Index > Fetch the complete documentation index at: https://docs.hiddenlayer.ai/llms.txt > Use this file to discover all available pages before exploring further. # Prerequisites - Helm ## Licenses **During Onboarding** * Username and Password * A username and password are provided during onboarding and is used to authenticate to HiddenLayer registries when downloading product images. * License IDs * License IDs are provided during onboarding and are used as the registry password when downloading HiddenLayer products. * The AI Security Platform: Self-Hosted/Air-Gapped install now bundles Runtime Security and AI Attack Simulation. | Product | License ID | | ------------------------------------------------------------------------- | ------------------------------- | | AI Security Platform (includes Runtime Security and AI Attack Simulation) | AI Security Platform License ID | ## Hostname * A hostname for the HiddenLayer AI Security Platform. * Example: `http://server1.test.hiddenlayer.com`. ## Supported Cloud Providers The AI Security Platform installation has been tested on AWS cloud infrastructure. The installation should work with other cloud providers. ## Services The below services are required for the Platform to be deployed and to function as expected. * For a detailed example of services, see [Example AWS](/docs/products/selfhosted/selfhosted_platform_example_aws). | Service | Service Type | Requirements | | ----------------------- | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Apache Kafka | Event Streaming | | | OpenSearch - Platform | Event/report indexing and query | | | OpenSearch - FusionAuth | Search indexes for the identity provider | | | PostgreSQL | Database | | | Redis | In-Memory Data Structure Store | | ## What the Cluster Must Provide The installer deploys only what is specific to the HiddenLayer AI Security Platform. It does not install, configure, or manage the cluster-level capabilities a production Kubernetes cluster is normally expected to provide. The HiddenLayer AI Security Platform depends on several cluster capabilities. Installing the AI Security Platform on a cluster that lacks these capabilities will appear to succeed, but the pods will stay `Pending` or storage requests will go unfulfilled. The following compute information is for the Helm installation of the AI Security Platform. For an Embedded Cluster installation, see the [Embedded Cluster Prerequisites](/docs/products/selfhosted/selfhosted_platform_embedded_prerequisites). ### K8s Kubernetes version 1.36 or newer. You must have administrator access to the cluster to install the AI Security Platform. ### Node Capacity and Scaling The AI Security Platform installer does not deploy a cluster autoscaler. The configuration exposes scheduling rules under `global.k8s.scheduling`, separately for CPU and GPU workloads. Node affinity and tolerations that determine where each class of workload is placed. ``` global: k8s: scheduling: cpu: affinity: {} tolerations: [] gpu: affinity: {} tolerations: [] ``` Whatever placement you express here must be satisfiable. Either run static nodes that match the rules, or run an autoscaler capable of adding nodes that do. If neither is true, the affected pods remain unschedulable indefinitely. Kubernetes reports this as Pending with an "unschedulable" event rather than as an install failure. The same applies to raw capacity. The platform requests meaningful CPU and memory, and nothing in the install expands the cluster to accommodate it. ### Persistent Storage The AI Security Platform installer does not deploy a storage provisioner or a CSI driver. Components that persist data request PersistentVolumeClaims and expect a working StorageClass to fulfill them. `global.k8s.storageClass` is read by the object store and the in-cluster PostgreSQL only. Every other component's claim goes to the cluster's default class. ``` global: k8s: storageClass: gp3 ``` If no usable class exists, PVCs stay `Pending` and the components that need them never start. A default StorageClass is required whatever `global.k8s.storageClass` is set to. The monitoring stack requests its volume without naming a class, in every install. This matters most where the installer deploys in-cluster copies of PostgreSQL, Kafka, OpenSearch or Redis. Supplying all five externally, as recommended for production, removes most of the platform's storage demand. ### GPU Nodes The AI Security Platform installer does not install the NVIDIA GPU Operator or any GPU device plugin on a bring-your-own cluster. CUDA GPU required for Runtime Security Examples: T4, A10, L4, L40, RTX PRO 4500, and RTX PRO 6000. For GPU workloads, the cluster must already expose schedulable GPU resources (drivers, container runtime support and device plugin in place) and `global.k8s.scheduling.gpu` must place those workloads onto the nodes that carry them. ### Ingress and External Exposure The AI Security Platform installer does not deploy an ingress controller or load balancer. It deploys an internal nginx proxy, which is the single entry point to the product and is exposed as a `ClusterIP` Service listening on 8443. Getting external traffic to that service is the cluster operator's responsibility. Common approaches: * Your own ingress controller. Set `global.ingress.enabled: true` and `global.ingress.ingressClassName` to your controller's class, and the installer creates an Ingress resource pointing at the proxy. The controller itself must already be running. * A Service of type LoadBalancer, a NodePort, or a gateway of your choosing, routed to the proxy service on 8443. TLS termination follows from that choice, either at your ingress or load balancer, or at the proxy. ### How Much Compute to Provision Approximate aggregate for the AI Security Platform's own workloads, with PostgreSQL, Kafka, OpenSearch and Redis supplied externally as recommended. It is a planning figure for sizing a node pool or an autoscaler's limits, not a guaranteed footprint. Actual usage scales with the traffic you send the AI Security Platform. | Resource | Requirements | | ------------------ | ------------------------------------------------------------- | | CPU | 16 vCPU | | Memory | 32 GB | | GPU | 1 GPU, on a node with a least 6 vCPU and 16 GB RAM of its own | | Persistent Storage | 50 GB, from your `StorageClass`. | **Other things about the table**: * **GPU is required** (`global.gpu.enabled: true`). One platform component uses a GPU, requesting a single device along with roughly 5 vCPU and 12 GB of RAM on the same node. Disabling the GPU is not recommended for production environments. * **Object storage runs in-cluster regardless**. The platform includes its own S3-compatible object store; there is no external-S3 option. It accounts for most of the persistent storage above. * **The figures exclude the four external data services**. Size those separately per infrastructure prerequisites. If you let the installer deploy in-cluster copies instead (evaluation only), add substantial CPU, memory and storage on top of these numbers. * Nodes must also leave room for whatever your cluster runs on every node: CNI, kube-proxy, logging agents, and the like. **Other cluster-level capabilities**: * Also assumed present, and not installed by the platform: DNS (CoreDNS or equivalent), a CNI, certificate issuance if you want automated TLS, and cluster-level logging, backup and monitoring. * The AI Security Platform ships its own application monitoring components; it does not manage the cluster's.