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 (Linux install), and run it on the target host as a user with sudo. rConfig creates the agent record, mints a one-shot bootstrap token, and generates a command that downloads a fixed installer, checks it against the published installer SHA256, and runs it with sudo. The installer downloads the binary, accepts it only if it is a published agent release, exchanges the token for a permanent api_token, writes .env, drops the systemd unit, and starts the service.

Changed in V8.4.1

The old curl … /vector/install.sh?bootstrap_token=… | sudo bash command no longer installs anything. Copy a new command from rConfig. Agents already installed are not affected.

Manual Binary Install

Best for: air-gapped or policy-restricted hosts where downloaded 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 downloaded 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.
• One host that reaches several separate networks, each only from its own address? From V8.4.1, run one agent per network on that host. See Running multiple agents on one host.

Read next

Manual Binary InstallDownload 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 APIOne 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 VectorThe agent record itself: what fields exist, how authentication works, what the source IP allowlist controls. Useful background for any of the three paths.