> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beyondguard.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# On-Premises Requirements for BeyondGuard
> Everything you need to run BeyondGuard fully on-premise — backing services, network access, storage, GPU, authentication, and LLM provider requirements, including air-gapped environments.
BeyondGuard runs **fully on-premise** as a containerized microservice stack, with no cloud dependency and no data leaving your environment. It supports both connected and **air-gapped** networks.
## Deployment options
Two installation methods are supported (see [Installation](/deployment/installation) for the process):
* **Helm** — for OpenShift and Kubernetes
* **Docker Compose** — for single-node deployments
## Backing services
The following services are required. Each can be **containerized** (provided by the installer) or supplied as an **existing external instance**, based on your infrastructure preference.
| Component | Version | Used for |
| - | - | - |
| **PostgreSQL** | 15+ | Primary datastore — configuration DB and log DB |
| **Redis** | Current | Cache manager for asynchronous services |
| **Kafka** | 3.x | Event bus for the audit-log pipeline |
## External network requirements
Most of the stack is internal-only. External access is needed in a few specific places:
* **Backend service** — reaches your **LLM provider** (cloud or on-prem) and, optionally, **LDAP / Active Directory** for user authentication.
* **During installation** — outbound access to the BeyondGuard **image repository** and **Helm repository** to pull deployment artifacts. In restricted or air-gapped environments, these can be mirrored to your internal registry or artifactory.
* **Guard microservices and the Service Engine** are internal-only and require no outbound internet access.
## Storage
Provision persistent volumes (PVCs) per service. Plan for a **minimum of 120 GB total** across all services; deployments that cache models and embeddings locally should plan for **300 GB or more**. The GPU model service requires its own large volume for model artifacts.
## GPU
The security model is served on a dedicated **GPU worker, deployed separately** from the application worker nodes. Two tiers are supported:
* **Minimum** — 48 GB vRAM (for example, 2× 24 GB GPUs), for roughly 20–30 concurrent requests.
* **High-capacity** — 94 GB vRAM (H100-class), for roughly 100–150 concurrent requests.
See [GPU & Performance](/deployment/gpu-performance) for sizing and benchmarks.
## Authentication
User authentication via **LDAP / Active Directory** is optional. If used, you provide the AD server host and port, base DN, and a service account if required.
## LLM provider
BeyondGuard is model-agnostic and routes to the provider you choose:
* **Cloud** — OpenAI, Anthropic Claude, Azure OpenAI, and others (with your API keys).
* **On-premises** — vLLM, Ollama, or another self-hosted endpoint. If an on-prem endpoint uses HTTP or a self-signed certificate, custom certificate trust (a CA bundle) is configured so the client can reach it securely.
The operating system and all required third-party software licenses are provided by BeyondGuard. Both physical and virtual infrastructure are supported. A short pre-deployment questionnaire (covering your deployment method, HA needs, network position, DNS, databases, storage class, monitoring, and timeline) is completed during onboarding to finalize the configuration.
## Related
Concrete CPU, memory, and GPU sizing.
The Helm and Docker Compose install process.
Network positioning for inline proxy inspection.
HA and disaster-recovery topology.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.