Collectors

A collector is the reachability domain that actually opens connections to devices and runs collections. Every source is bound to one. There are two kinds: the embedded collector built into the core, and standalone collectors you deploy near networks the core can’t reach directly.

Collectors are a platform-wide primitive, so they live under Settings → System → Collectors — not inside the Configuration Tracker section.

	Embedded	Standalone
Runs	In-process on the core (leader) node	As a separate container at a site
Setup	None — it’s built in	Deploy + enroll (see the deploy guide)
Reaches	Whatever the core can reach on the network	Devices local to its site
Connection to core	It is the core	Dials out to the core (outbound only)
Best for	Single-site / flat networks	Segmented, remote or NAT’d networks; multi-site
Count	Exactly one, the default, undeletable	As many as you need

The embedded collector is seeded at first boot as “Local (built-in)”, is always the default, and can’t be deleted. For a single site it’s all you need — point sources at it and go.

The Collectors list under Settings → System: the built-in Local collector, online, with the count of sources and addresses using it.

standalone collector · site-eu

segmented site

collector 0 ports open

dials out only →

Taranac core

Ed25519 identity credential-free at rest durable outbox

A standalone collector is designed so that deploying one into a sensitive segment adds as little attack surface as possible:

• Dial-out only — listens on zero ports. The core never connects to a collector. The collector makes outbound connections to the core, long-polls for work, and streams results back. There is no inbound listener to expose or firewall.
• Reveal-once Ed25519 identity. A collector enrolls with a one-time token and then proves itself on every request by signing with an Ed25519 key it generates locally and never sends. The core pins the collector’s public key on first enrollment; each subsequent request carries a signature and a timestamp, checked within a tight clock-skew window to defeat replay.
• Credentials handed out just-in-time. A collector receives the credentials for a collection only in the poll response for that work, uses them in memory, and keeps nothing long-lived — including just-in-time passwords, which rotate the moment the collector’s work drains.
• Credential-free at rest. The collector persists its own identity key and a durable result outbox, but no device credentials — a stolen disk yields no way into your fleet.
• Durable outbox. Results are buffered locally and delivered idempotently, so a restart or a brief link outage never loses a capture or double-writes one.
• Trust-on-first-use host keys. SSH host keys are pinned per device on first sight and a later mismatch is refused — the same TOFU model the embedded collector uses.

The Collectors list shows each collector’s mode, status and when it was last seen.

Status is derived from the last time a collector reported in — it isn’t a stored flag, so a wedged collector reads correctly:

Status	Meaning
Online	Reported in recently (within the staleness window). The embedded collector is always online.
Offline	Hasn’t reported within the window (about 15 minutes — many missed polls, a deliberately coarse signal).
Unknown	Has never reported (freshly created, not yet enrolled/started).

A standalone collector’s identity is managed from its detail page:

• Enroll / Re-enroll issues a reveal-once enrollment token (with a TTL you choose, default 60 minutes) plus a ready-to-paste join command. The token is shown once — copy it then. Issuing a new token revokes any previous pending one.
• Revoke identity invalidates the collector’s key immediately: its very next signed request is rejected. Re-enrolling issues a fresh token and identity.

The full deploy walkthrough is in Deploy a standalone collector.

The core and a standalone collector must agree on a snapshot-identity version — the contract covering how configs are scrubbed and hashed. Every poll carries the collector’s version; on a mismatch the core fail-closes: it dispatches no work and ingests nothing from that collector until it’s upgraded to match. A version-skewed collector idled is safer than one silently writing inconsistent history.

One flat site. Do nothing — use the embedded Local (built-in) collector for every source.

A remote branch behind NAT. Deploy a standalone collector at the branch, enroll it, and set your branch sources’ collector to it. Nothing needs to be opened inbound to the branch or the core.

A hardened DMZ or OT segment. Put a standalone collector inside the segment. It reaches the gear locally and dials out to the core — no inbound path into the segment, no device credentials stored on the collector.

Situation	Collector
Core can reach the devices directly	Embedded
Devices are in a segment the core can’t route to	Standalone
Site is behind NAT / has no inbound path	Standalone (dial-out)
Multiple sites, each isolated	One standalone per site
You need zero new inbound listeners in a sensitive zone	Standalone

Field	Notes
Mode	embedded (Local (built-in), single, default, undeletable) or standalone.
Status	online · offline · unknown — derived from last-seen, not stored.
Identity	Standalone only: Ed25519 key pinned at enrollment; status active or revoked.
Enrollment token	Reveal-once; operator-chosen TTL (default 60 min); one live token at a time.
Compatibility	Snapshot-identity version must match the core; mismatch fail-closes.
Used by	Sources and tracked-config addresses referencing the collector (blocks deletion).

• Deploy a standalone collector — the operator guide.
• Tracked configs & transports — sources pick a collector.
• Credentials & the vault — the run-scoped credential hand-out.
• Change alerts & safe deletion — the collector-offline alert.