Deployment models
There's one collector to deploy, and one decision to make up front: how does AI traffic reach it? Everything else — sizing, CA trust, HA — follows from that. This page helps you choose; the pages under it walk each model in detail.
Where you do this: This page is a decision guide — no commands. Each sub-page below opens with its own Where you do this callout naming the exact surface (cloud dashboard, collector host, agent host, DHCP server, MDM, or your existing forward proxy) for every step.
The one thing to decide: how traffic is routed
Kilasec only inspects traffic that reaches the collector's proxy. You get it there in one of two ways:
| Model | How traffic arrives | Best when | Guide |
|---|---|---|---|
| PAC file (auto-config) | DHCP hands clients a proxy.pac URL; clients auto-route AI-provider domains to the collector | You control DHCP and want zero per-device config | Single-site |
| Agent-host config script | A one-line script points a server/VM's env proxy at the collector; the collector sorts scope | The machines are servers/VMs running agents or SDKs (not browsers), which ignore PAC | Agent hosts |
| Explicit proxy chain | You already run a forward proxy (Squid, Zscaler, a NGFW); you chain AI-provider traffic through the collector | You have an existing egress proxy and prefer to route through it | Explicit proxy |
All three end at the same place — the collector on :8080. PAC is the lightest touch for browser fleets; the config script is the right fit for agent/SDK hosts (which don't read PAC — see how scope is applied); explicit-proxy chaining fits shops that already funnel egress through infrastructure they control.
Where the collector runs
The collector is a single hardened Docker container. It needs:
- A Linux host with systemd (amd64 or arm64) — a small VM, a NUC, a Pi 4/5, or a spare box. Not macOS/Windows as a host; the installer is systemd-based.
- Docker 24+ — installed automatically by the installer if missing.
- Outbound HTTPS (443) to
kilasec.comfor the control-plane uplink. - Reachability from your clients on
:8080(proxy) and:9443(PAC), on the LAN.
It runs read-only, non-root, --cap-drop=ALL, no-new-privileges. See Install a collector for the one-liner and Sizing & failure modes for hardware.
The one piece that touches devices: the CA
To inspect TLS without warnings, clients must trust the collector's CA. This is the only step that reaches endpoints, and it's normally a one-time push via MDM/Jamf/Intune/GPO. It's the most common source of onboarding friction, so it has its own guide: Trusting the inspection CA.
A typical rollout
- Stand up the collector on a Linux host and approve it in the dashboard.
- Distribute the CA to a pilot group of devices (CA distribution).
- Route traffic for that pilot group (single-site or explicit-proxy).
- Verify a real AI call shows up in Live Traffic (Generate test traffic).
- Start in observe mode — policy defaulting to
log/allow— watch what's actually on the network, then tighten rules. - Expand the CA + routing to the rest of the fleet.
Rolling out to a pilot group first is strongly recommended: you validate CA trust and routing on a handful of machines before touching everyone.
Sizing at a glance
One collector comfortably handles a small-to-mid site. Scale by adding collectors (one per site/subnet is common) rather than one giant box. Full guidance — CPU/RAM, throughput, and what happens when a collector or the cloud goes down — is in Sizing & failure modes.
Next
- Single-site deployment (PAC) — the common case.
- Agent hosts (config script) — for servers/VMs running agents.
- Explicit-proxy chaining.
- Trusting the inspection CA.
- Sizing & failure modes.