Deployment

Arbitex Gateway supports three deployment topologies. Each provides the same enforcement capabilities — DLP inspection, Policy Engine evaluation, audit logging, and multi-provider routing — with different data residency and operational characteristics.

flowchart LR
    subgraph SaaS["SaaS (Cloud-Managed)"]
        C1["Client Apps"] --> AG1["Arbitex Gateway\n(Arbitex Cloud)"]
        AG1 --> P1["LLM Providers"]
    end

    subgraph Hybrid["Hybrid Outpost"]
        C2["Client Apps"] --> OP["Arbitex Outpost\n(Your VPC)"]
        OP --> P2["LLM Providers"]
        OP -. "mTLS\npolicy sync\naudit sync" .-> CP["Arbitex Cloud\n(Control Plane)"]
    end

    subgraph SelfHosted["Self-Hosted"]
        C3["Client Apps"] --> AG3["Arbitex Platform\n(Your Infrastructure)"]
        AG3 --> P3["LLM Providers"]
    end

Topology comparison

	SaaS	Hybrid Outpost	Self-Hosted
Data path	Prompts and responses traverse Arbitex Cloud	Prompts and responses stay in your VPC	All data on your infrastructure
Control plane	Arbitex-operated	Arbitex-operated (Cloud API)	You operate
DLP engine	Runs in Arbitex Cloud	Runs locally in your VPC	Runs on your infrastructure
Policy management	Cloud Portal UI + API	Synced from Cloud every 60s via mTLS	Admin API on your platform instance
Audit log	Arbitex Cloud (90-day buffer) + your SIEM	Local buffer, batch-forwarded to Cloud every 30s	Local PostgreSQL + your SIEM
User management	Cloud Portal; Entra ID SCIM	Managed via Cloud Portal	Local platform; Entra ID SCIM
Offline resilience	N/A	Cached policy bundle allows enforcement during Cloud outage	Always-on (no external dependencies)
Plan tiers	Developer Free, Developer Pro, Team, Enterprise	Enterprise Outpost	N/A

SaaS (cloud-managed)

The default deployment. Your applications send requests to the Arbitex Gateway endpoint in Arbitex Cloud. The gateway handles routing, DLP, policy enforcement, and audit logging. You manage configuration through the Cloud Portal or the admin API.

How it works

Your application sends POST /v1/chat/completions to https://gateway.arbitex.ai/v1
The gateway authenticates the request, runs DLP inspection, evaluates the policy chain, and routes to the provider
The response passes through output scanning (if configured) and is returned to your application
An audit log entry is written atomically

What you configure

Provider API keys (Settings > Providers)
Policy packs and chain (Settings > Policies or the Policy Pack API)
User and group quotas (Billing and metering)
SIEM connectors (Audit log — SIEM integration)
Entra ID SCIM provisioning (Entra ID SCIM)

Network requirements

Direction	Destination	Port	Protocol
Outbound from your apps	`gateway.arbitex.ai`	443	HTTPS
Outbound from your apps	`api.arbitex.ai` (admin API)	443	HTTPS

No inbound connections to your infrastructure are required.

Hybrid Outpost

The Hybrid Outpost runs the data plane inside your VPC. Prompts and responses never leave your network — only metadata (audit entries, policy sync requests) crosses the boundary to Arbitex Cloud via mTLS. This topology is for organizations with data residency requirements that prevent AI traffic from traversing third-party infrastructure.

How it works

Your application sends requests to the Outpost endpoint inside your VPC (default port 8300)
The Outpost runs DLP inspection and policy evaluation locally using cached policy bundles
The Outpost forwards the request directly to the LLM provider from your network
Audit metadata is written to a local buffer (JSONL) and batch-forwarded to Arbitex Cloud every 30 seconds
Policy bundles are synced from Arbitex Cloud every 60 seconds via mTLS (ETag-based; no transfer on no change)

Component inventory

Each Outpost deployment consists of the following services:

Component	Docker service	Port	Purpose
Proxy / API gateway	`backend`	8100 (admin API), 8300 (proxy)	Core request pipeline: authentication, DLP orchestration, Policy Engine, provider proxying, audit logging
Admin UI	`frontend`	3100	React/Nginx admin portal — proxies `/api/` to the backend. Exposes policy management, SIEM config, group and quota management
DLP NER engine	`ner-gpu`	8200	GPU-accelerated zero-shot NER microservice (GLiNER model). Detects unstructured PII: names, addresses, medical terms. Optional — Outpost functions without it at reduced detection coverage
DLP contextual validator	`deberta-validator`	8201	DeBERTa NLI microservice. Second-pass contextual validation to suppress false positives from Tier 1/2. Requires GPU. Disabled by default (`DLP_DEBERTA_ENABLED=false`)
Database	`postgres`	5432	PostgreSQL 16 — stores org config, policy packs, audit log, group memberships, SIEM connector state. Isolated to `backend-net`
Cache	`redis`	6379	Rate limiting hot path (token bucket via INCR/EXPIRE). Syncs to PostgreSQL every 60 seconds. Isolated to `backend-net`

Network topology

flowchart TD
    subgraph VPC["Your VPC — backend-net (internal)"]
        PG["PostgreSQL :5432"]
        RD["Redis :6379"]
        NER["NER GPU :8200"]
        DEB["DeBERTa :8201"]
        BE["Backend (proxy + API)\n:8100 admin / :8300 proxy"]
    end

    subgraph VPC2["Your VPC — frontend-net"]
        FE["Admin UI :3100"]
    end

    Apps["Client Apps"] -->|":8300 HTTP/S"| BE
    AdminBrowser["Admin Browser"] -->|":3100 HTTPS"| FE
    FE -->|"/api/ reverse proxy"| BE
    BE --> PG
    BE --> RD
    BE -->|"POST /detect"| NER
    BE -->|"POST /validate"| DEB
    BE -->|"direct from your network"| LLM["LLM Providers\napi.openai.com\napi.anthropic.com"]

    BE -."mTLS outbound only\nPolicy sync every 60s\nAudit sync every 30s".-> Cloud["Arbitex Cloud\napi.arbitex.ai"]
    BE -."mTLS outbound only\nCert renewal".-> CloudCerts["Arbitex Cloud\ncloud.arbitex.ai"]

backend-net is an internal Docker network — PostgreSQL and Redis are not reachable from outside the Docker environment. frontend-net connects only the backend and frontend; the frontend cannot reach the database directly.

Resource requirements

Minimum requirements for a production Outpost without GPU microservices (Tier 1 DLP only):

Component	Memory	CPU	Storage
`postgres`	512 MB	1 core	20 GB+ (audit log retention)
`redis`	256 MB	0.5 core	—
`backend`	1 GB	2 cores	—
`frontend`	256 MB	0.5 core	—
Total (no GPU)	~2 GB	~4 cores	20 GB+

With GPU microservices enabled (Tier 2 + Tier 3 DLP):

Component	Memory	CPU	GPU
`ner-gpu`	4 GB	1 core	1× NVIDIA GPU (any CUDA-capable)
`deberta-validator`	4 GB	1 core	1× NVIDIA GPU (can share with NER)
Additional (GPU)	+8 GB	+2 cores	1–2× GPU

NER and DeBERTa can share a single GPU if VRAM > 8 GB. Both services require CUDA and NVIDIA Container Toolkit. GPU microservices have a cold start time of approximately 60 seconds for model loading.

Deployment options

Docker Compose — for VMs and bare-metal deployments. The docker-compose.yml in the Outpost repository starts the full stack. For GPU microservices, ensure the NVIDIA Container Toolkit is installed and docker compose up has GPU access.

Kubernetes / Helm — the charts/arbitex-outpost/ Helm chart provides production-ready deployment with configurable replica count, PodDisruptionBudget, and optional HorizontalPodAutoscaler. GPU nodes require the nvidia.com/gpu resource label.

Network requirements

Direction	Destination	Port	Protocol	Purpose
Inbound (VPC internal)	`backend`	8300	HTTP/HTTPS	Client AI requests
Inbound (VPC internal)	`frontend`	3100	HTTPS	Admin portal
Outbound	`api.arbitex.ai`	443	HTTPS + mTLS	Policy sync, audit sync
Outbound	`cloud.arbitex.ai`	443	HTTPS + mTLS	Certificate renewal
Outbound	LLM providers	443	HTTPS	Model proxying (direct from your network)

The Outpost initiates all connections to Arbitex Cloud — no inbound connections from Arbitex to your VPC are required.

Certificate management and rotation lifecycle

Each Outpost receives a unique mTLS certificate bundle at registration time. Certificates authenticate the Outpost to Arbitex Cloud for policy sync, audit sync, and cert renewal.

Certificate files on the Outpost:

Path	Purpose	Mode
`/app/certs/outpost.pem`	Outpost leaf certificate (public)	0644
`/app/certs/outpost.key`	Outpost private key	0400
`/app/certs/ca.pem`	Arbitex Platform CA certificate — used to verify Cloud server identity	0644

Rotation lifecycle:

sequenceDiagram
    participant O as Outpost
    participant C as Arbitex Cloud

    Note over O: D-30: cert renewal window opens
    O->>C: POST /v1/internal/cert-renew (mTLS with current cert)
    C->>C: Issue new 90-day leaf cert signed by Platform CA
    C-->>O: new_cert.pem + private_key (encrypted)
    O->>O: Write new cert to /app/certs/ (atomic replace)
    O->>O: Reload TLS context (no restart required)
    Note over O: Old cert remains valid for 30 days overlap

    Note over O: D-0: old cert expires
    O->>O: Remove old cert, new cert is sole identity

Key points:

Validity: 90 days per certificate
Renewal window: Opens 30 days before expiry. The Outpost checks for renewal eligibility on every policy sync cycle.
Overlap period: Old and new certs are both valid for 30 days after renewal, preventing hard cutover issues during gradual rollouts.
Atomic replacement: The cert file is written atomically (temp file + rename) to prevent partial reads during rotation.
No restart required: The backend TLS context reloads the new cert on the next connection establishment without a service restart.
If renewal fails: The Outpost logs a warning and retries on the next sync cycle. If the cert expires before renewal succeeds, mTLS connections to Arbitex Cloud fail — policy sync and audit sync stop. Local policy enforcement continues using the cached bundle; audit events buffer locally and replay when connectivity is restored.

Certificate renewal alert: Monitor the cert expiry date using the Outpost health endpoint (GET /health returns cert_expires_at). Configure an alert when cert_expires_at is within 7 days.

Offline resilience

If the Outpost loses connectivity to Arbitex Cloud:

Policy enforcement continues using the last cached policy bundle. The cache is persisted to a PVC (Kubernetes) or a named Docker volume. The Outpost serves requests indefinitely from cache.
Audit entries buffer locally in JSONL format on a mounted volume. When connectivity is restored, the buffer is forwarded to Cloud in sequential order, preserving the audit chain HMAC integrity.
Certificate renewal fails while offline. Plan for connectivity before the 90-day cert expiry. Extended offline operation (> 60 days) risks cert expiry.

Key configuration

Variable	Default	Description
`OUTPOST_ID`	—	UUID assigned at registration
`PLATFORM_MANAGEMENT_URL`	`https://api.arbitex.ai`	Platform management plane endpoint
`POLICY_SYNC_INTERVAL`	`60`	Seconds between policy sync checks
`AUDIT_SYNC_INTERVAL`	`30`	Seconds between audit batch uploads
`DLP_ENABLED`	`true`	Enable/disable the local DLP pipeline
`DLP_NER_BACKEND`	`default`	NER backend: `default` (CPU Presidio), `microservice` (GPU :8200)
`DLP_DEBERTA_ENABLED`	`false`	Enable Tier 3 contextual validation (requires GPU microservice)
`AUDIT_HMAC_KEY`	—	Base64-encoded HMAC key (32+ bytes) for audit chain integrity

Self-hosted

The full Arbitex platform deployed on your infrastructure. You operate the control plane, data plane, and all supporting services. No connection to Arbitex Cloud is required.

Services

Service	Port	Description
PostgreSQL	5432	Primary database
Redis	6379	Rate limiting, JWT revocation cache
Backend (FastAPI)	8000	Gateway API, admin API, DLP, policy engine
Frontend (React)	3000	Admin portal
NER microservice	8200	GPU-accelerated named entity recognition (optional)
DeBERTa validator	8201	GPU-accelerated contextual validation (optional)

Network isolation

The Docker Compose configuration uses two networks:

backend-net (internal): PostgreSQL, Redis, Backend, NER, DeBERTa — not reachable from outside Docker
frontend-net: Backend, Frontend — the frontend reverse-proxies /api/ to the backend

GPU requirements

Tier 2 (NER) and Tier 3 (DeBERTa) DLP microservices require NVIDIA GPU access. If GPUs are not available, the DLP pipeline runs Tier 1 (pattern matching) only. See DLP Overview for tier capabilities.

Choosing a topology

Requirement	Recommended topology
Fastest deployment, no infrastructure to manage	SaaS
Data residency — prompts must not leave your network	Hybrid Outpost
Full operational control, no external dependencies	Self-hosted
Compliance frameworks requiring data sovereignty	Hybrid Outpost
Air-gapped or disconnected environments	Self-hosted

Deployment

Topology comparison

SaaS (cloud-managed)

How it works

What you configure

Network requirements

Hybrid Outpost

How it works

Component inventory

Network topology

Resource requirements

Deployment options

Network requirements

Certificate management and rotation lifecycle

Offline resilience

Key configuration

Self-hosted

Services

Network isolation

GPU requirements

Choosing a topology

See also