Distributed config collection. One agent per site, every device covered.

The rConfig Vector Agent is a lightweight Go binary that runs as a systemd or Windows service at each site, tenant, or network segment you need to manage. It polls local network devices over SSH, SNMP, Uptime, and HTTP, stores work in a durable SQLite queue, and syncs configs and logs back to a central rConfig server over outbound-only TLS.

Because real networks are segmented. A single central collector either accumulates inbound firewall exceptions from every site until the security team revolts, or it gives up on coverage. The Vector Agent replaces that model. Every site gets its own collector, the agents dial out to rConfig, and no inbound firewall rules are required.

Linux and Windows, amd64 and arm64. It speaks SSH (including full interactive-shell support with enable mode, pager handling, and legacy-device quirks for Cisco, Avaya, and HP ProCurve), SNMP, Uptime, and HTTP. The same protocol surface rConfig's core collector supports.

The agent only makes outbound TLS connections to rConfig. It pulls jobs, pushes results, and streams logs, all on the same outbound channel. rConfig never initiates a connection to the agent. This matches the zero-trust posture most infosec teams already require for new agents.

Nothing is lost. Jobs and logs persist in local SQLite with WAL journaling. On restart, the agent replays unfinished work. If the rConfig API is unreachable, the agent keeps collecting and queues results locally. The log syncer drains the backlog when connectivity returns, with 413-aware batch splitting and bounded retry amplification.

Two axes. Vertically, each agent has a dynamic worker pool: you set worker_count on the rConfig side and the pool scales up or down without restart. Horizontally, you deploy more agents. Agents are stateless except for their local queue, so adding a site is a binary drop plus an API key, not a coordination exercise.

Yes. Put the agent inside the segment with a single outbound rule to the rConfig API. SSH credentials and device traffic stay local to the OT segment; only signed, structured job results cross the boundary. Many customers use this pattern for NIS2, NERC-CIP, and internal OT compliance.

The agent ships as part of the rConfig MSP and Enterprise license. The architecture, interfaces, and operational guardrails are fully documented. For licensing details, see pricing or speak to the team.

Device connection parameters (username, password, SSH key material, enable secrets) are delivered per-job from rConfig over TLS. The agent uses them during the job, persists only the minimum needed for queue durability, and keeps them local to the site. Credentials never leave the site perimeter.

rConfig V8 and later, with the Vector-Server Laravel package installed. Earlier rConfig versions used a different collection model. If you're on V7 or below, contact the team about upgrading before deploying agents.

Download the agent binary from the rConfig download page, run the installer script (it registers a systemd unit on Linux or a service on Windows), drop your API URL and agent key into the local .env, and start the service. Total install time is usually under a minute per site.

Every job and error emits a structured log event to local SQLite, which the log syncer streams to rConfig under size-bounded batching. You get the job ID, ULID, worker ID, device, protocol, elapsed time, and outcome for every fetch. Pathological records that trigger repeated 413s get quarantined locally rather than silently dropped.