--- title: "Network Architecture and Requirements" slug: "network-requirements" updated: 2026-10-20T10:29:18Z published: 2026-10-20T10:29:18Z canonical: "docs.verax.ai/network-requirements" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.verax.ai/llms.txt > Use this file to discover all available pages before exploring further. # Network Architecture and Requirements This article describes the supported network deployment models for Verax and the network connectivity requirements needed to operate Verax securely in cloud, on-premises, and hybrid environments. Verax is deployed as a network-accessible service that inspects and enforces policy on generative AI traffic. It supports private, public, and hybrid deployment models, with identity-based enforcement applied consistently across all options. --- ## Supported Deployment Models Verax supports the following deployment models: 1. **Private network deployment** 2. **Private deployment with public ingress (hybrid)** 3. **Public endpoint deployment with identity enforcement** The appropriate model depends on how users access AI tools and how your organization prefers to enforce trust, through network boundaries, identity, or both. --- ## Option A: Private Network Deployment In this model, Verax is deployed entirely within a **private network segment**, such as a private subnet, internal network zone, or restricted VLAN. This option is recommended when: - Users access the internet through a corporate network or VPN - AI traffic flows through centralized egress points - Network-level isolation is required ### Characteristics - Verax is not directly exposed to the public internet - Inbound access is limited to internal networks or trusted routing components - Outbound internet access is provided through controlled egress [Diagram: private deployment on AWS - example] ![](https://cdn.document360.io/0db41097-2a23-4e2b-9fae-aecb3e4383d9/Images/Documentation/base64-converted-image-1792492003735.png) --- ## Option B: Private Deployment with Public Ingress (Hybrid) In this model, Verax remains deployed in a **private network**, but remote users access it through a **controlled public entry point**, such as a load balancer or reverse proxy. This option is recommended when: - You need to support work-from-home or remote users - Users are not consistently connected through a VPN - You want to avoid exposing Verax directly to the internet ### Characteristics - Verax has only private IP addresses - A public-facing ingress component exposes a public IP or DNS name - Traffic is routed from the ingress component to Verax over private networking - Network exposure is limited to the ingress layer This model combines strong network isolation with support for remote users. [Diagram: private deployment with public ingress on AWS - example] ![](https://cdn.document360.io/0db41097-2a23-4e2b-9fae-aecb3e4383d9/Images/Documentation/base64-converted-image-1792492003736.png) --- ## Option C: Public Endpoint Deployment with Identity Enforcement In this model, Verax is deployed with a **public IP address or public-facing endpoint** and is reachable directly by both local and remote users. Access is restricted using **identity enforcement at the proxy level**, rather than relying on network location. This option is recommended when: - Users operate from multiple locations and networks - VPN usage is limited or unavailable - You want a single, consistent access path for all users ### Characteristics - Verax is publicly reachable - No implicit trust is granted based on network location - All access is gated by identity verification - Only authenticated and authorized organization users can route traffic through Verax Verax Protect enforces identity at the proxy layer, ensuring that only verified organizational users can access the service, even when exposed through a public endpoint. [Diagram: public deployment on AWS - example] ![](https://cdn.document360.io/0db41097-2a23-4e2b-9fae-aecb3e4383d9/Images/Documentation/base64-converted-image-1792492003737.png) --- ## Inbound Connectivity (to Verax) ### Management and Agent Communication — TCP 3000 (Required) TCP 3000 is required for Verax management access and endpoint agent communication. These ports must be accessible from: - Managed endpoints (for agent registration and ongoing communication) - Trusted administrative networks (for management console access) ### Administrative Access — TCP 22 (optional) - Used for SSH access by administrators - Allow only from trusted administrative IP addresses - Optional and not required for normal operation ### HTTP Proxy Traffic — TCP 443 (conditional) - Required if traffic is routed to Verax using a web proxy endpoint - Applies to DNS-based routing, PAC files, NAT, or host-based redirection ### ICAP Traffic — TCP 1344 (conditional) - Required only if ICAP-based traffic redirection is used - Commonly used with secure web gateways or firewalls that support ICAP --- ## Outbound Connectivity (from Verax) ### HTTPS — TCP 443 (required) Outbound HTTPS access is required for: - Proxying requests to generative AI tools - Accessing Verax update services and hotfixes - General outbound connectivity required for normal operation No additional outbound ports are required. --- ## Security Considerations - Choose network isolation, identity enforcement, or a combination of both based on your security model - Restrict inbound access to trusted sources and required ports only - Prefer controlled ingress components when exposing Verax publicly - Identity enforcement ensures that public exposure does not imply public access - Network location alone should not be treated as a trust signal --- ## Summary Verax supports flexible deployment models to fit modern enterprise environments: - **Private deployments** for network-isolated environments - **Hybrid deployments** for remote users with controlled public ingress - **Public endpoint deployments** secured through identity enforcement Across all models, Verax applies consistent inspection, rule evaluation, and enforcement, allowing organizations to adopt generative AI securely without compromising visibility or control.