Choosing an Agent Deployment Method

There are three supported ways to deploy a Vector Agent onto a target host. They produce the same end state (an enabled, registered agent with a permanent API token and a running vectoragent systemd service); they differ only in how much of the work you do by hand. Pick whichever matches the size of your fleet and the level of automation you already have.

Version availability

The UI Install Command and Manual Binary Install paths work on every Vector release. The Automated REST API path requires rConfig V8.2.1 or later. If you are on an earlier version, upgrade the Vector Server first or use one of the other two paths.

The three paths

UI Install Command

Best for: one agent, occasional adds, hands-on operators with a browser already open.

Click Add Agent, fill the form, copy the install command shown on the next screen, paste it into a root shell on the target host. rConfig creates the agent record, mints a one-shot bootstrap token, and generates a curl ... bash install line that downloads the binary, exchanges the token for a permanent api_token, writes .env, drops the systemd unit, and starts the service.

Manual Binary Install

Best for: air-gapped or policy-restricted hosts where piped shell installers are not allowed.

Download the binary from the rConfig portal, transfer it to the host, place it under /usr/local/bin/rconfig, write .env by hand using values copied from the rConfig UI, write a systemd unit, enable and start. rConfig provides the binary and the values for .env. No remote connection required from the rConfig server during install.

Automated REST API

Best for: fleets of agents deployed from Ansible, Terraform, CI, or any other runbook tool.

Call POST /api/v2/agents/provision for each host, capture the returned install_command, and run it on the target host as part of your existing rollout pipeline. End-to-end this is the same install as the UI path, with the bootstrap step exposed as an idempotent JSON endpoint so the whole flow fits inside a runbook.

Note

All three paths end with the same agent state in the database. You can mix and match without consequence: an agent provisioned by API can later be edited in the UI, and an agent created in the UI can have a fresh install command generated by API for re-rollout.

Quick decision guide

• Provisioning one agent and you have a browser open? Use the UI install command and copy it into a shell on the target host.
• Need to deploy across a handful of agents but the targets are air-gapped or have strict supply-chain rules against piped shell installers? Use the manual binary install.
• Provisioning more than three or four agents, especially if you already use Ansible/Terraform/CI to push other things to those hosts? Use the REST API path.

Read next

Manual Binary Install Download the binary, place it on the host, write .env and the systemd unit by hand. Includes the UI Install Script flow as a quicker alternative on the same page.

Automated Deployment via REST API One POST per host. Capture the returned install command in your runbook and run it on the target. Idempotent on agent name, so re-runs are safe.

Adding Agents to Vector The agent record itself: what fields exist, how authentication works, what the source IP allowlist controls. Useful background for any of the three paths.