Deployment topologies guide

Arbitex supports two primary deployment modes — SaaS and Self-hosted (Outpost) — and several derived topologies that combine or extend them. This guide is intended for architects and operators evaluating deployment options. It covers request flow, network requirements, sizing, and decision criteria for each pattern. For hands-on deployment instructions, see Outpost Deployment and Outpost Operations.

---

1. Overview

Every Arbitex deployment intercepts LLM API traffic, applies DLP policies, and records audit events. What differs between topologies is where that interception happens and who manages the infrastructure.

SaaS routes traffic through the Arbitex Cloud gateway hosted on Azure. There is no on-premises component. Arbitex manages availability, scaling, and updates. Suitable for organizations that accept cloud-hosted processing of their LLM request payloads.

Self-hosted (Outpost) deploys a proxy process on infrastructure you control. Traffic never leaves your network boundary. Arbitex does not process request payloads. Suitable for air-gap, strict data-residency, on-premises, or compliance environments where cloud payload processing is prohibited.

Hybrid runs both simultaneously. Cloud workloads use SaaS; sensitive or on-premises workloads use an Outpost. Both report to the same cloud portal for unified policy and audit management.

Deployment mode decision framework

Requirement	Recommended mode
No on-prem infrastructure available	SaaS
Cloud payload processing is acceptable	SaaS
Data must not leave your network	Outpost
Air-gap or no internet connectivity	Outpost (air-gap variant)
Mixed environment (cloud + on-prem)	Hybrid
Strict data residency (country-level)	Outpost or Hybrid
Fastest time to production	SaaS

Note

The SaaS gateway and Outpost proxy are functionally equivalent from the client’s perspective. Both accept OpenAI-compatible API requests and return OpenAI-compatible responses. The API key and base URL differ; application code changes are minimal.

---

2. SaaS topology

In the SaaS topology, clients send requests to the Arbitex Cloud gateway at api.arbitex.ai/v1. The gateway inspects the request, applies DLP rules, and forwards to the configured LLM provider. Responses are inspected on the return path before being delivered to the client.

Request flow

Client application
       │
       │  POST /v1/chat/completions
       │  Authorization: Bearer <arbitex-api-key>
       ▼
┌─────────────────────────────────────────────────────┐
│              Arbitex Cloud Gateway                  │
│              api.arbitex.ai/v1                      │
│                                                     │
│  1. Authenticate API key                            │
│  2. Route to workspace policy                       │
│  3. DLP scan — request                              │
│  4. Forward to LLM provider                         │
│  5. DLP scan — response                             │
│  6. Return to client                                │
└─────────────────────────────────────────────────────┘
       │
       │  Forwarded request
       ▼
┌─────────────────────────────────────────────────────┐
│              LLM Provider                           │
│  (OpenAI, Azure OpenAI, Anthropic, etc.)            │
└─────────────────────────────────────────────────────┘

Multi-tenant architecture

The SaaS gateway is a multi-tenant service. Each workspace is logically isolated:

• API keys are scoped to a workspace.
• DLP rules, routing config, and audit logs are workspace-scoped.
• No cross-workspace data access.

Compute is shared at the infrastructure layer. If your compliance posture requires dedicated compute, use Outpost.

Azure cloud hosting

The Arbitex Cloud platform runs on Microsoft Azure. Current deployment region: East US (default). Additional regions available on Enterprise plans:

Region	Availability
East US (default)	All plans
West Europe	Enterprise
Southeast Asia	Enterprise

Tip

If your organization requires data residency in a specific country and that region is not listed, contact Arbitex sales. Region expansion is on the roadmap. In the interim, an Outpost deployment satisfies country-level residency requirements without waiting for a new SaaS region.

Latency profile

The SaaS gateway adds approximately 20ms round-trip latency for a standard DLP scan. This includes:

• TLS termination and re-establishment to LLM provider: ~5ms
• Policy lookup and rule evaluation: ~3ms
• DeBERTa inference (cloud-side, GPU-backed): ~10ms
• Audit event write (async, non-blocking): ~0ms added to request path

The 20ms figure is for requests up to ~2,000 tokens. Larger prompts scale approximately linearly with token count through the DLP scan phase.

Prompt size	Added latency (approx.)
≤ 500 tokens	~12ms
500–2,000 tokens	~20ms
2,000–8,000 tokens	~45ms
> 8,000 tokens	~80ms

Caution

These are representative figures measured from Azure East US to OpenAI US endpoints. Latency to other LLM providers or from different client regions will differ. Measure against your specific provider and client location before establishing SLAs.

High availability and failover

The SaaS gateway runs as a horizontally scaled service behind an Azure Front Door load balancer. Redundancy configuration:

• Minimum two gateway instances per region at all times.
• Automatic failover within a region on instance failure (typically < 5s).
• Cross-region failover is not automatic. In a regional outage, clients fall through to the configured LLM provider directly (bypassing Arbitex inspection). Alert configuration for gateway reachability is recommended.

SLA targets

Metric	Target
Monthly uptime	99.9%
P99 gateway latency (DLP on, 2k tokens)	< 100ms
DLP rule propagation	< 60s after portal save

SLA credits apply to Enterprise plans per the terms of service. Developer and Team plans receive best-effort availability.

---

3. Outpost topology

An Outpost is a self-hosted reverse proxy that runs on infrastructure you control. Clients on your network send LLM API requests to the Outpost. The Outpost applies DLP policies locally and forwards to the LLM provider. No request payload leaves your network.

For detailed architecture internals, see Outpost Architecture.

Request flow

Client application (internal network)
       │
       │  POST http://outpost.internal:8080/v1/chat/completions
       │  Authorization: Bearer <workspace-api-key>
       ▼
┌─────────────────────────────────────────────────────┐
│              Outpost Proxy                          │
│              outpost.internal:8080                  │
│                                                     │
│  1. Authenticate API key (local validation)         │
│  2. Apply workspace policy (local config)           │
│  3. DLP scan — request (local DeBERTa)              │
│  4. Forward to LLM provider                         │
│  5. DLP scan — response (local DeBERTa)             │
│  6. Write audit log (local storage)                 │
│  7. Return response to client                       │
└─────────────────────────────────────────────────────┘
       │
       │  Outbound HTTPS to LLM provider
       ▼
┌─────────────────────────────────────────────────────┐
│              LLM Provider                           │
│  (OpenAI, Azure OpenAI, Anthropic, etc.)            │
└─────────────────────────────────────────────────────┘

       (Optional: heartbeat/config sync)

┌─────────────────────────────────────────────────────┐
│              Arbitex control plane                  │
│              your-platform-host                     │
│  - Receives heartbeat                               │
│  - Pushes policy updates                            │
│  - Receives audit log stream (if configured)        │
└─────────────────────────────────────────────────────┘

Network requirements

Outbound (required):

Destination	Port	Purpose
LLM provider endpoints (e.g., api.openai.com)	443/TCP	LLM request forwarding
your-platform-host	443/TCP	Heartbeat, config sync (disable in air-gap)

Inbound (required from client network only):

Source	Port	Purpose
Client applications	8080/TCP (default)	LLM proxy requests
Admin operators	8443/TCP (default)	Admin API

Note

No inbound connections from the internet are required for Outpost operation. The Outpost initiates the outbound heartbeat connection to the cloud portal — the portal does not call back to the Outpost. This is intentional for firewall-friendly deployments.

Deployment

Docker Compose

The canonical Outpost deployment uses Docker Compose. A minimal docker-compose.yml:

version: "3.9"
services:
  outpost:
    image: arbitex/outpost:latest
    ports:
      - "8080:8080"
      - "8443:8443"
    volumes:
      - ./config:/etc/arbitex/outpost
      - ./data:/var/lib/arbitex/outpost
      - ./logs:/var/log/arbitex/outpost
    environment:
      - ARBITEX_WORKSPACE_ID=${WORKSPACE_ID}
      - ARBITEX_OUTPOST_TOKEN=${OUTPOST_TOKEN}
      - ARBITEX_CONFIG_FILE=/etc/arbitex/outpost/config.yaml
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3

Start the Outpost:

docker compose up -d

Kubernetes

For Kubernetes deployments, the Outpost runs as a standard Deployment with a ClusterIP or LoadBalancer service depending on client access pattern.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: arbitex-outpost
  namespace: arbitex-system
spec:
  replicas: 2
  selector:
    matchLabels:
      app: arbitex-outpost
  template:
    metadata:
      labels:
        app: arbitex-outpost
    spec:
      containers:
        - name: outpost
          image: arbitex/outpost:latest
          ports:
            - containerPort: 8080
            - containerPort: 8443
          envFrom:
            - secretRef:
                name: arbitex-outpost-credentials
          volumeMounts:
            - name: config
              mountPath: /etc/arbitex/outpost
            - name: data
              mountPath: /var/lib/arbitex/outpost
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
            requests:
              cpu: "2"
              memory: "4Gi"
            limits:
              cpu: "4"
              memory: "8Gi"
      volumes:
        - name: config
          configMap:
            name: arbitex-outpost-config
        - name: data
          persistentVolumeClaim:
            claimName: arbitex-outpost-data
---
apiVersion: v1
kind: Service
metadata:
  name: arbitex-outpost
  namespace: arbitex-system
spec:
  selector:
    app: arbitex-outpost
  ports:
    - name: proxy
      port: 8080
      targetPort: 8080
    - name: admin
      port: 8443
      targetPort: 8443
  type: ClusterIP

Config management

The Outpost reads configuration from a YAML file at startup. The default path is /etc/arbitex/outpost/config.yaml. A minimal config:

workspace_id: "ws_xxxxxxxxxxxxxxxx"
outpost_token: "${ARBITEX_OUTPOST_TOKEN}"

proxy:
  listen_addr: "0.0.0.0:8080"
  tls_listen_addr: "0.0.0.0:8443"

dlp:
  model_path: "/var/lib/arbitex/outpost/models/deberta"
  device: "cpu"          # or "cuda" for GPU

audit:
  local_path: "/var/log/arbitex/outpost/audit"
  retention_days: 90

cloud_sync:
  enabled: true
  endpoint: "https://your-platform-host"
  heartbeat_interval: 60s

Hot-reload: Send SIGHUP to the Outpost process to reload config without downtime:

docker compose kill -s SIGHUP outpost
# or in Kubernetes:
kubectl exec -n arbitex-system deploy/arbitex-outpost -- kill -HUP 1

Tip

Config changes that affect DLP model loading (e.g., switching device from cpu to cuda) require a full restart, not just SIGHUP. All other config keys support hot-reload.

---

4. Hybrid topology

The hybrid topology runs SaaS and Outpost simultaneously. Cloud-originated workloads use the SaaS gateway. On-premises or sensitive workloads route through an Outpost. Both are managed from a single cloud portal workspace.

Use case

A typical hybrid deployment looks like:

• Developer laptops and CI/CD pipelines: route to SaaS (api.arbitex.ai/v1)
• Production inference on-premises: route to Outpost (outpost.internal:8080)
• Both are in the same workspace
• DLP rules are defined once in the portal and sync to the Outpost

Control plane convergence

┌──────────────────────────────────────────────┐
│           Arbitex control plane              │
│           your-platform-host                 │
│                                              │
│  - Workspace policy (single source of truth) │
│  - DLP rule management                       │
│  - Unified audit log view                    │
└──────────────────┬───────────────────────────┘
                   │
          ┌────────┴────────┐
          │                 │
          ▼                 ▼
┌─────────────────┐  ┌─────────────────────┐
│  SaaS Gateway   │  │  Outpost Proxy      │
│  api.arbitex.ai │  │  outpost.internal   │
│                 │  │                     │
│  Cloud clients  │  │  On-prem clients    │
└────────┬────────┘  └──────────┬──────────┘
         │                      │
         ▼                      ▼
┌─────────────────────────────────────────────┐
│              LLM Providers                  │
└─────────────────────────────────────────────┘

DLP rule synchronization

DLP rules are the single source of truth in the cloud portal. The Outpost polls the portal for updates on a configurable interval (default: 60 seconds). Rule propagation is pull-based: the Outpost initiates the request. No portal-to-Outpost push path exists; this preserves the no-inbound-connection constraint.

Sync behavior:

• On startup: Outpost fetches full ruleset from portal.
• Every cloud_sync.rule_poll_interval seconds: Outpost checks for ruleset version bump and fetches delta if changed.
• On SIGHUP: Outpost immediately polls for latest rules.

If the portal is unreachable, the Outpost continues operating with the last-known ruleset. Stale-ruleset age is surfaced in the health endpoint and portal.

Audit log handling

In hybrid mode, audit logs flow from two sources:

Source	Default behavior	Cloud-visible
SaaS gateway	Written directly to cloud audit log	Yes, immediately
Outpost	Written to local disk	Only if cloud_sync.audit_ship: true

To enable audit log shipping from Outpost to cloud:

cloud_sync:
  enabled: true
  audit_ship: true
  audit_batch_size: 100
  audit_ship_interval: 30s

Caution

Enabling audit_ship causes audit log records (including any redacted content summaries) to be transmitted to Arbitex Cloud. If your data residency policy prohibits this, leave audit_ship: false and manage Outpost audit logs separately.

---

5. Air-gap variant

The air-gap variant is a fully offline Outpost deployment. There is no connection to the Arbitex Cloud control plane. All configuration, policy management, and audit log retention happens on-premises.

When to use air-gap

• Defense contractors and government classified environments
• Nuclear facility or critical infrastructure operators
• Financial institutions with strict network segmentation requirements
• Any environment where outbound internet connectivity is prohibited

Air-gap configuration

Set cloud_sync.enabled: false in config:

workspace_id: "ws_xxxxxxxxxxxxxxxx"
outpost_token: "${ARBITEX_OUTPOST_TOKEN}"

proxy:
  listen_addr: "0.0.0.0:8080"

dlp:
  model_path: "/var/lib/arbitex/outpost/models/deberta"
  device: "cuda"

audit:
  local_path: "/var/log/arbitex/outpost/audit"
  retention_days: 365

cloud_sync:
  enabled: false      # Disables all outbound cloud connectivity

With cloud_sync.enabled: false, the Outpost makes no outbound connections except to LLM provider endpoints (which may themselves be air-gapped using local model inference).

DeBERTa model — local loading

In air-gap mode, the DeBERTa classification model must be pre-loaded from a local path. The model cannot be fetched at runtime.

1. On an internet-connected machine, download the Arbitex-packaged DeBERTa model:

   arbitex-cli model pull deberta-v3-base-arbitex --output ./deberta-model.tar.gz

2. Transfer deberta-model.tar.gz to the air-gapped host via approved media (USB, secure file transfer, etc.)

3. Extract to the model path:

   tar -xzf deberta-model.tar.gz -C /var/lib/arbitex/outpost/models/

4. Verify the model loads correctly:

   arbitex-cli model verify /var/lib/arbitex/outpost/models/deberta

Policy management in air-gap mode

Without cloud sync, policies are managed via config files. The Outpost reads policy rules from a local YAML file:

/etc/arbitex/outpost/policies/workspace-policy.yaml

rules:
  - id: "pii-block"
    name: "Block PII in requests"
    direction: request
    action: block
    detectors:
      - type: deberta
        label: PII
        threshold: 0.85
      - type: regex
        pattern: '\b\d{3}-\d{2}-\d{4}\b'   # SSN pattern

  - id: "secrets-block"
    name: "Block secrets in requests"
    direction: request
    action: block
    detectors:
      - type: regex
        pattern: '(?i)(api[_-]?key|secret|password)\s*[:=]\s*\S+'

To update rules, edit the policy file and send SIGHUP. No portal access required.

Periodic sync workflow (optional)

For environments that have occasional controlled connectivity windows (e.g., weekly sync allowed), the arbitex-cli provides an export/import workflow:

# On internet-connected portal access machine:
arbitex-cli policy export --workspace ws_xxx --output policy-export-2026-03-15.yaml

# Transfer to air-gapped host, then:
arbitex-cli policy import --file policy-export-2026-03-15.yaml \
  --config /etc/arbitex/outpost/policies/workspace-policy.yaml

# Reload:
kill -HUP $(pgrep arbitex-outpost)

Note

Audit logs in air-gap mode remain on-premises indefinitely. Implement log rotation (audit.retention_days) and off-site backup using your existing secure archival procedures. Arbitex does not provide air-gap audit log management tooling beyond local retention configuration.

---

6. Multi-Outpost deployment

Multiple Outpost instances are independent. There is no built-in clustering, leader election, or distributed state between Outpost instances. Each instance runs its own copy of the DeBERTa model, holds its own audit logs, and independently polls the cloud portal for policy updates.

Common multi-Outpost patterns

Environment isolation (dev / staging / prod):

Each environment gets its own Outpost instance, optionally its own workspace. Policy rules can differ per environment (e.g., staging may have more permissive rules for testing).

Regional deployment:

One Outpost per data center or cloud region. Clients in each region point to their local Outpost. Reduces latency by co-locating the proxy with clients.

Network segment isolation:

One Outpost per security zone. Clients in a restricted zone send traffic to an Outpost also within that zone. No traffic crosses zone boundaries.

Load balancing multiple Outpost instances

To scale throughput or provide HA within an environment, run multiple Outpost instances behind a load balancer. Since Outpost instances are stateless (no session affinity required), any L4 or L7 load balancer works.

nginx

upstream arbitex_outpost {
    least_conn;
    server outpost-1.internal:8080;
    server outpost-2.internal:8080;
    server outpost-3.internal:8080;
}

server {
    listen 80;
    server_name outpost.internal;

    location / {
        proxy_pass http://arbitex_outpost;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 120s;
        proxy_connect_timeout 10s;
    }
}

HAProxy

frontend arbitex_frontend
    bind *:8080
    default_backend arbitex_outpost

backend arbitex_outpost
    balance leastconn
    option httpchk GET /health
    http-check expect status 200
    server outpost-1 outpost-1.internal:8080 check
    server outpost-2 outpost-2.internal:8080 check
    server outpost-3 outpost-3.internal:8080 check

Config management across instances

There is no centralized config distribution mechanism. Options:

• Configuration management tools: Ansible, Puppet, Chef — push identical config to all instances.
• Shared volume: Mount the config directory from NFS or a similar shared filesystem (read-only mount on each Outpost node, writable on management host only).
• Container image baking: Embed config at build time for immutable deployments.

Caution

If using shared config volumes, ensure that outpost_token is not shared between instances intended to represent distinct logical Outpost registrations in the portal. Each instance should have its own token if you want per-instance visibility in the portal. Tokens may be shared if you want all instances to appear as one logical Outpost.

---

7. Network diagrams

SaaS topology

  ┌──────────────────────────────────────────────────────────────────┐
  │  Client network                                                  │
  │                                                                  │
  │  ┌─────────────────────┐                                         │
  │  │  Client application │                                         │
  │  │  (browser / server) │                                         │
  │  └──────────┬──────────┘                                         │
  └─────────────│────────────────────────────────────────────────────┘
                │ HTTPS 443
                │ POST api.arbitex.ai/v1/chat/completions
  ══════════════╪══════════════ Internet boundary ═══════════════════
                │
  ┌─────────────▼────────────────────────────────────────────────────┐
  │  Arbitex Cloud (Azure East US)                                   │
  │                                                                  │
  │  ┌──────────────────────────────────────────────────────────┐    │
  │  │  Azure Front Door (load balancer)                        │    │
  │  └──────────────┬─────────────────────────────────────────┘    │
  │                 │                                               │
  │  ┌──────────────▼──────────────────────────────────────────┐   │
  │  │  Gateway cluster                                        │   │
  │  │  - Auth, routing, DLP scan, audit write                 │   │
  │  └──────────────┬──────────────────────────────────────────┘   │
  │                 │                                               │
  │  ┌──────────────▼──────────────────────────────────────────┐   │
  │  │  Control plane (your-platform-host)                     │   │
  │  │  - Policy store, audit DB, workspace mgmt               │   │
  │  └─────────────────────────────────────────────────────────┘   │
  └─────────────────────────────────────────────────────────────────┘
                │
                │ HTTPS 443
  ══════════════╪══════════════ Internet boundary ═══════════════════
                │
  ┌─────────────▼────────────────────────────────────────────────────┐
  │  LLM Provider (e.g., api.openai.com)                            │
  └──────────────────────────────────────────────────────────────────┘

Outpost topology

  ┌──────────────────────────────────────────────────────────────────┐
  │  Corporate / on-premises network                                 │
  │                                                                  │
  │  ┌─────────────────────┐                                         │
  │  │  Client application │                                         │
  │  └──────────┬──────────┘                                         │
  │             │ HTTP(S) 8080                                       │
  │             │ POST outpost.internal/v1/chat/completions          │
  │  ┌──────────▼──────────────────────────────────────────────┐    │
  │  │  Outpost proxy (outpost.internal:8080)                  │    │
  │  │  - Auth, DLP scan (DeBERTa local), audit local          │    │
  │  └──────────┬──────────────────────────────────────────────┘    │
  │             │                                                    │
  │  ┌──────────▼──────────────────────────────────────────────┐    │
  │  │  Firewall / egress proxy                                │    │
  │  └──────────┬──────────────────────────────────────────────┘    │
  └─────────────│────────────────────────────────────────────────────┘
                │ HTTPS 443 (outbound only)
  ══════════════╪══════════════ Internet boundary ═══════════════════
                │
          ┌─────┴──────┐
          │            │
          ▼            ▼
  ┌──────────────┐  ┌──────────────────────────┐
  │ LLM Provider │  │ Arbitex control plane    │
  │ api.openai.. │  │ your-platform-host       │
  │              │  │ (heartbeat + policy sync) │
  └──────────────┘  └──────────────────────────┘

Hybrid topology

  ┌──────────────────────────────────────────────────────────────────┐
  │  Corporate network                                               │
  │                                                                  │
  │  ┌─────────────────┐     ┌──────────────────────────────────┐   │
  │  │  Dev / CI/CD    │     │  Production / sensitive           │   │
  │  │  client apps    │     │  client apps                     │   │
  │  └────────┬────────┘     └──────────┬───────────────────────┘   │
  └───────────│────────────────────────┼──────────────────────────-─┘
              │ HTTPS 443              │ HTTP(S) 8080
              │ api.arbitex.ai         │ outpost.internal
  ════════════╪════════════════════════│═══ Internet boundary ═══════
              │                        │
              ▼                        │ (stays on-prem)
  ┌───────────────────────────┐        │
  │  Arbitex SaaS (managed)   │        │
  │                           │◄───────┤ policy sync (outbound)
  │  Control plane            │        │
  │  your-platform-host       │        │
  │  (unified policy + audit) │        │
  └───────────┬───────────────┘        │
              │                ┌───────▼────────────────────────┐
              │                │  Outpost proxy                 │
              │                │  outpost.internal:8080         │
              │                │  (DLP local, audit local)      │
              │                └───────────────────────────────-┘
              │                        │
  ════════════╪════════════════════════╪═══ Internet boundary ═══════
              │                        │
              ▼                        ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  LLM Provider (api.openai.com, etc.)                            │
  └──────────────────────────────────────────────────────────────────┘

Air-gap topology

  ┌──────────────────────────────────────────────────────────────────┐
  │  Air-gapped network (no internet connectivity)                   │
  │                                                                  │
  │  ┌─────────────────────┐                                         │
  │  │  Client application │                                         │
  │  └──────────┬──────────┘                                         │
  │             │ HTTP 8080                                          │
  │  ┌──────────▼──────────────────────────────────────────────┐    │
  │  │  Outpost proxy (air-gap mode)                           │    │
  │  │  cloud_sync.enabled: false                              │    │
  │  │                                                         │    │
  │  │  - Auth from local config                               │    │
  │  │  - DLP: DeBERTa from local model path                   │    │
  │  │  - Policy: file-based YAML                              │    │
  │  │  - Audit: local disk only                               │    │
  │  └──────────┬──────────────────────────────────────────────┘    │
  │             │                                                    │
  │  ┌──────────▼──────────────────────────────────────────────┐    │
  │  │  Local / on-prem LLM inference                          │    │
  │  │  (e.g., vLLM, Ollama, Azure OpenAI private endpoint)   │    │
  │  └─────────────────────────────────────────────────────────┘    │
  │                                                                  │
  │  ┌─────────────────────────────────────────────────────────┐    │
  │  │  Audit log storage (local disk / NAS)                   │    │
  │  └─────────────────────────────────────────────────────────┘    │
  │                                                                  │
  │  ══════════════ Network perimeter (no outbound) ═══════════════  │
  │                                                                  │
  │  Policy updates: secure media transfer (USB / SFTP jump host)   │
  └──────────────────────────────────────────────────────────────────┘

---

8. Decision matrix

Use this matrix to match your requirements to a deployment topology. A filled cell means the topology satisfies that requirement; a dash means it does not (or requires additional configuration).

Requirement	SaaS	Outpost	Hybrid
Air-gap / no internet egress	—	Yes (air-gap variant)	—
Strict data residency (country-level)	EU/AP on Enterprise only	Yes	Yes (on-prem traffic via Outpost)
No cloud payload processing	—	Yes	Partial (on-prem traffic only)
Multi-tenant OK (shared compute)	Yes	—	Partial
Managed infrastructure (no ops burden)	Yes	—	Partial
On-premises hardware available	Not required	Required	Required (for on-prem traffic)
Compliance audit trail on-prem	—	Yes	Yes (Outpost traffic)
Unified policy management	Yes	Yes (cloud sync)	Yes
Fastest deployment	Yes	—	—
GPU for production DLP throughput	Managed	Self-managed	Self-managed (Outpost)
HA without self-managing	Yes	— (self-managed)	Partial
Per-request latency < 15ms added	— (~20ms)	Yes (GPU)	Depends

Note

“Hybrid” in this matrix refers to the control plane only — unified policy management via cloud portal. The data plane for on-premises traffic in a hybrid deployment behaves identically to a standalone Outpost for all data-handling requirements.

---

9. Sizing guide

SaaS

No sizing required. The SaaS gateway scales automatically. There are no capacity limits exposed to operators. For throughput-sensitive workloads, contact Arbitex support to confirm rate limits for your plan tier.

Outpost sizing

Production and air-gap Outpost deployments require a GPU (NVIDIA T4 minimum; L4 / A10 or ≥ 24 GB VRAM recommended) — the Presidio + GLiNER NER backend and the DeBERTa Tier 3 validator run GPU inference. CPU-only inference remains available for development and evaluation only. See Hardware requirements for the full spec.

CPU-only deployment

Resource	Minimum	Recommended
CPU	2 cores	4 cores
RAM	4 GB	8 GB
Storage (OS + binaries)	10 GB	20 GB
Storage (audit logs)	20 GB	50 GB (with rotation)
Network	100 Mbps	1 Gbps

At 4 cores / 8 GB, expect approximately 8–12 req/s throughput with DLP enabled on 2k-token prompts.

GPU-accelerated deployment (recommended for production)

Resource	Minimum	Recommended
CPU	4 cores	8 cores
RAM	8 GB	16 GB
GPU	1x NVIDIA (6GB VRAM)	1x NVIDIA A10G or better
CUDA version	12.0+	12.3+
Storage (OS + binaries + model)	30 GB	50 GB
Storage (audit logs)	50 GB	200 GB (with rotation)
Network	1 Gbps	10 Gbps

With GPU acceleration, expect approximately 80–150 req/s throughput with DLP enabled on 2k-token prompts. Actual throughput depends on GPU model and prompt size.

Caution

The DeBERTa model occupies approximately 1.5 GB of GPU VRAM at float32 precision. Cards with less than 6 GB VRAM should use device: cpu or load the model at float16 precision. Loading DeBERTa at float16 reduces VRAM to approximately 800 MB with minimal accuracy impact for most policy configurations.

Storage planning

Audit log volume depends on request rate and verbosity settings. At audit.verbosity: standard (default):

Request rate	Audit log volume per day
10 req/s	~500 MB/day
50 req/s	~2.5 GB/day
100 req/s	~5 GB/day

Configure log rotation to prevent disk exhaustion:

audit:
  local_path: "/var/log/arbitex/outpost/audit"
  retention_days: 90
  max_disk_gb: 100      # Outpost will warn and begin dropping oldest logs if exceeded

Tip

For compliance environments with long audit retention requirements, mount the audit log path on a dedicated volume separate from the OS disk. This allows independent capacity management and simplifies backup procedures.

Kubernetes resource requests

The Kubernetes example in section 3 specifies requests: cpu: "2", memory: "4Gi" and limits: cpu: "4", memory: "8Gi". These are appropriate starting values for CPU-only deployment. For GPU deployments, add:

resources:
  requests:
    cpu: "4"
    memory: "8Gi"
    nvidia.com/gpu: "1"
  limits:
    cpu: "8"
    memory: "16Gi"
    nvidia.com/gpu: "1"

Ensure your cluster has the NVIDIA device plugin installed and nodes are labeled appropriately.

---

Further reading

• Outpost Deployment — step-by-step installation, registration, and first-run validation
• Outpost Operations — day-two operations: upgrades, config management, health monitoring, log management
• Outpost Architecture — internals: request pipeline, DLP engine, config model, audit subsystem