Sizing & failure modes

How much hardware a collector needs, how to scale, and — most importantly — what happens to traffic when something fails. Plan the failure behavior before you roll out; it's a policy decision, not a default to accept blindly.

Sizing a collector

A collector's work is TLS termination + a fast policy evaluation per request. It's CPU-light and memory-modest.

	Minimum	Comfortable
CPU	2 cores	4 cores
RAM	512 MB free	1–2 GB
Disk	2 GB (image) + ~50 MB/day audit	10 GB+
Network	outbound 443 to kilasec.com; LAN reach on :8080/:9443	same

A small VM, a NUC, or a Raspberry Pi 4/5 (arm64) handles a typical office. The bottleneck under load is TLS handshakes, not policy evaluation — size CPU to your concurrency, not your rule count.

Scaling: out, not up

Add more collectors rather than one large one:

• One per site / subnet is the common pattern — it keeps interception local and avoids routing AI traffic across your WAN just to inspect it.
• Each collector enrolls independently and appears separately in Fleet health.
• Policy and scope are managed centrally in the cloud and pulled by every collector, so more collectors doesn't mean more policy work.

There's no shared-state requirement between collectors — they're independent enforcement points reporting to one control plane.

Failure modes — decide these deliberately

If the cloud (kilasec.com) is unreachable

The collector keeps enforcing policy locally — it already has the current rules on disk. Decisions are buffered to disk and flush to the cloud when connectivity returns. You lose live dashboard visibility during the outage, not enforcement. Policy/scope changes you make in the dashboard simply apply once the collector can pull them again.

If the collector itself is down

This is the important one, and the answer depends on your routing:

• PAC-based routing: a well-written PAC returns PROXY <collector>; DIRECT — clients try the collector, and if it's unreachable they fall back to direct (fail-open: AI calls still work, but are not inspected). If you instead want fail-closed (AI calls blocked when the collector is down), the PAC must return PROXY <collector> with no DIRECT fallback — then a dead collector blocks AI traffic.
• Explicit-proxy chaining: behavior is whatever your upstream proxy does when the collector peer is unreachable — configure never_direct (fail-closed) or allow direct (fail-open) on the proxy side.

Choose based on your risk posture: fail-open favors availability (a collector outage never breaks users' AI tools); fail-closed favors control (nothing reaches a provider uninspected). For most beta deployments, fail-open on a monitored collector is the pragmatic choice — pair it with offline alerting so you know immediately when a collector drops.

Restart / recovery

The collector runs under systemd with Restart=always; a crashed process comes back on its own. It buffers to disk and drains cleanly on shutdown, so a restart doesn't lose decisions.

Backups

Collector state is disposable — it re-enrolls and re-pulls policy. The thing worth backing up is the cloud database (your tenants, policy, audit history). If you self-host the cloud, ensure a nightly DB snapshot is in place; the Kilasec-hosted cloud handles this for you.

Monitoring is part of the plan

A collector you can't see is a collector you can't trust. Before rollout, make sure Fleet health and offline alerting are set up so a dead collector pages you rather than silently failing open. See Monitoring & health.