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.
What are the deployment modes?
Section titled “What are the deployment modes?”- 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.
How is it sized?
Section titled “How is it sized?”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.
What are the software prerequisites?
Section titled “What are the software prerequisites?”| 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.
What ships in the box?
Section titled “What ships in the box?”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.
What are the reference topologies?
Section titled “What are the reference topologies?”| 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.
How are upgrades and rollbacks handled?
Section titled “How are upgrades and rollbacks handled?”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.
What about data residency?
Section titled “What about data residency?”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.
How do I stand up a first instance?
Section titled “How do I stand up a first instance?”The full procedure, including sizing and TLS, is in the Install & Setup Guide; for Kubernetes see the Amazon EKS Install Guide. The short version:
docker compose up -dcurl -s http://localhost:8787/health # {"ok":true,"version":"…"}Then sign in as the initial super-admin, create your organization, add a provider key, and send one request. Those five minutes tell you whether TLS, the database and an upstream all work — before anyone else is invited.
How do I upgrade?
Section titled “How do I upgrade?”docker compose pull && docker compose down && docker compose up -dcurl -s https://<your-agentwatch-host>/healthVerify the version you intended is the version running. A pull that silently
kept a cached image is the failure to guard against — compare the version in
/health with the tag you deployed, and treat a mismatch as a failed upgrade
rather than assuming the tag is right.
Upgrades are a plain image swap: schema changes are applied on boot, and recent feature work deliberately stores state in settings rather than new tables so an upgrade does not need a migration window.
What should I check after an upgrade?
Section titled “What should I check after an upgrade?”| Check | Command |
|---|---|
| Version is what you deployed | curl -s …/health |
| An LLM call still works | a minimal /v1/chat/completions |
| Settings still save | change one field in Company Policy |
| Scanners loaded | GET /admin/dlp/ner/status |
| Traffic is recording | one request, then Usage Insights |
Running more than one instance
Section titled “Running more than one instance”Multiple instances behind a load balancer share the database and support rolling upgrades with in-flight request preservation. Two consequences worth planning for: settings caches are per process (a change is live within ~30s everywhere, not instantly), and anything holding process-local state — the event pipeline singleton — reads the platform row rather than a per-organization copy.
Sources and references
Section titled “Sources and references”- Configuration reference: Configuration and admin.
- Security posture: Security and compliance.