Managing collectors

A collector is one enforcement point on your network. This is the lifecycle: enroll → approve → operate → upgrade → retire.

Where you do this: Cloud dashboard — kilasec.com/app/ → Collectors. Requires the tenant_admin role. Two steps (running the installer, restarting a container) happen on the collector host and are called out inline.

Enroll

In the dashboard: go to Collectors → Add collector. You'll get a per-collector enrollment code and a ready-to-paste install command.

On the collector host: run the one-liner as root. The collector enrolls and lands back in the dashboard's Collectors list under pending approval — its token works only for status polling; it can't inspect or ingest anything until you approve it.

Approve (the security gate)

In the dashboard → Collectors → Pending. Enrollment is intentionally out-of-band: a freshly-enrolled collector does nothing until a human approves it. Before you click Approve, the pending card shows three things to sanity-check:

• Source IP — did it come from where you expect?
• Host fingerprint — a stable identifier for the machine.
• User-agent — the installer/version that enrolled.

Verify those, then hit Approve. Approval is a signed-in admin action — a collector can't approve itself. Reject invalidates the token immediately.

If a collector enrolls but never heartbeats within ~10 minutes (e.g. the install half-failed), a sweeper auto-revokes it so the list doesn't fill with ghosts. Pending rows older than 24h are auto-rejected.

Operate

Once approved and heartbeating, a collector shows online (see Monitoring). In the dashboard → Collectors → click the row to open its detail panel, where you can:

• Download the CA certificate and copy the PAC URL (for network setup and CA distribution).
• Run a verify command to confirm interception.
• Set a source-IP allowlist — restrict which client IPs the collector will proxy for.

Apply policy / restart

Collectors pull policy and scope from the cloud. Most changes take effect on the collector's next pull. When you need them applied immediately, hit Apply now on Policy Rules — it signals the collectors to restart and re-read config. A restart is graceful: buffers drain, then the container comes back (systemd Restart=always).

Upgrade

Collector builds reach you on a release channel, and your workspace tracks one of them:

Channel	Who is on it
canary	Kilasec's own collectors. Every build lands here first.
early	Design partners who asked for changes early.
stable	The default for every workspace.

A build only moves up a channel when Kilasec promotes it, and a promotion is blocked until the build has been carrying live traffic on the channel below for a set period with no failed upgrades behind it. That means "a new build exists" and "a new build is offered to you" are different events — your collectors are never handed something that hasn't soaked somewhere else first.

Your channel is shown on the Collectors page next to the auto-upgrade toggle, and the version each collector runs is in the list.

Taking upgrades

• Auto-upgrade on (Collectors → Auto-upgrade): collectors move to your channel's build on their own, a few every five minutes rather than all at once. If upgrades start failing, the rollout freezes itself rather than working through the rest of your fleet.
• Auto-upgrade off (the default): each collector's row shows update available when your channel has a newer build; Upgrade applies it on your schedule.

Either way, a build that won't start is caught on the host: the collector reverts to the last version that ran healthily, so a bad upgrade doesn't leave you without inspection.

Maintenance window

An upgrade restarts the collector, which drops inline inspection for a few seconds. If that has to happen at a specific hour, set a window — auto-upgrades then only start inside it:

PUT /v1/auto-update-policy
{"upgrade_window": "02-06", "upgrade_timezone": "America/Los_Angeles"}

Leave it empty (the default) and upgrades can start at any time. Windows may wrap midnight (22-04). Manual Upgrade clicks ignore the window — that is you choosing the moment.

Retire

In the dashboard → Collectors → click the row → Drain & delete. The dashboard signals shutdown, the collector flushes its buffers, confirms, writes a shutdown sentinel so systemd won't resurrect it, and stops. The row is then purged.

To simply cut one off without a graceful drain, use Revoke on the same panel — its next call returns 401.

Multiple collectors

Run one per site/subnet; each enrolls and is approved independently and appears separately in the Collectors list. They share centrally-managed policy and scope, so more collectors is more coverage, not more admin. See Sizing & scaling.