Skip to content
Docs

Deployment

AgentWatch is CPU-only software with no GPU requirement — model inference happens at the provider or on a customer-hosted inference cluster, while AgentWatch is the governance and observability layer in front of it. That makes deployment a straightforward containerized rollout.

  • Self-hosted — Docker or Kubernetes on customer infrastructure; data never leaves the corporate network.
  • SaaS — Iterate.ai-hosted multi-tenant instance for fastest time to value.
  • Hybrid — control plane in one environment, data plane in the customer VPC.
  • Air-gapped — container plus embedded database plus a local model runtime, with zero outbound dependency; images, model weights, and library mirrors are pulled once at install time from an internal registry. Suitable for classified, sovereign, and heavily regulated deployments.
  • Developer laptop — a single compiled binary with an embedded database and a local model runtime, offline capable.

Three reference tiers cover most deployments. All are pure software — no specialized hardware.

Small Medium Large
Users up to 300 300–500 500–1,000+
Footprint Single container App container + managed PostgreSQL Two app instances (HA) + PostgreSQL + event streaming + analytics DB
Database Embedded Managed PostgreSQL PostgreSQL HA with connection pooling and read replicas
CPU / RAM 2 vCPU / 2 GB 6 vCPU / 8 GB 20 vCPU / 32 GB
Storage 20 GB SSD 120 GB SSD 540 GB SSD
Network 1 GbE 1 GbE 1–10 GbE

Because LLM proxying is I/O-bound, throughput is gated by upstream provider latency rather than AgentWatch CPU. As a reference, a single instance handles roughly 5–10 requests/second at 100 users and 50–100 at 1,000 users; beyond that, add application replicas behind a load balancer. The optional code-knowledge feature is the one component with a materially larger footprint and is sized separately.

Component Minimum
Container runtime Docker 20.10+, containerd 1.6+, or Kubernetes 1.24+
Database PostgreSQL 14+ for production; embedded database for small and edge tiers
Load balancer HAProxy 2.x, NGINX 1.20+, or a cloud load balancer (AWS, GCP, Azure)
Object storage Any S3-compatible service (S3, GCS, Azure Blob, MinIO, R2)
Identity provider Any OIDC-compliant provider, or SAML 2.0, or LDAP/Active Directory
Event streaming / analytics Optional — file-based fallback included

Host platforms: Ubuntu 22.04/24.04 LTS, Debian 11/12, RHEL 8+, or Amazon Linux 2023, on x86_64 or ARM64 (including AWS Graviton and Azure Cobalt) via multi-architecture images. SSD is required for the database tier; NVMe is preferred at the large tier.

Multi-architecture container images, a Helm chart with a pre-hardened security context (non-root, no privilege escalation, minimal capabilities), Docker Compose files for single-host and event-pipeline variants, a single compiled binary for air-gapped and edge installs, signed endpoint-agent installers for macOS, Windows, and Linux, Kubernetes manifests and a Helm chart for the fleet agent, a full API test collection with a CI runner, and architecture reference diagrams for each deployment pattern.

Topology When to use
Direct integration Applications → AgentWatch → providers. Simplest; dev, internal tools, lower-compliance use cases.
Behind a corporate proxy / CASB All egress traverses Zscaler, Forcepoint, or Netskope. Required where CASB controls are mandatory.
Load-balanced HA Multiple replicas behind a load balancer with PostgreSQL replicas. For 500+ users with formal SLAs.
Transparent proxy DNS resolves provider hostnames to AgentWatch. No application changes at all — drop-in shadow-AI elimination for brownfield estates.
Dedicated egress / colocation Egress via a dedicated interconnect to provider regions for predictable latency and cost.
Customer-hosted inference AgentWatch in front of your own inference clusters — including Lifeboat, vLLM, TGI, or Triton — so all traffic stays inside the boundary. Strongest data-residency posture.

Multi-region active/active is supported through a stateless application tier, cross-region database replicas, and global DNS load balancing.

Upgrades are an image swap; schema changes are applied and backfilled automatically at boot, so no manual migration step is required. Multi-instance deployments support zero-downtime rolling upgrades — drain a node, upgrade it, return it to the pool — with in-flight requests preserved through a graceful shutdown window. Documented rollback procedures and a pre-upgrade checklist accompany each release, and an encrypted backup and restore facility covers disaster recovery.

Each deployment is region-local by design: audit records, usage data, and embeddings stay inside the deployment region, and only the model calls leave — to the providers the customer has explicitly authorized. Replacing those with self-hosted inference closes the loop entirely.