Agent configuration
The agent reads every setting from a single config.yml. This page documents each section, what the settings do, and their defaults.
Every agent process reads its settings from one file, config.yml, mounted at /etc/vaurd/config.yml in the container images. The platform generates most of it for you during registration; you fill in the parts specific to your infrastructure.
The agent does not read configuration from the environment. Every setting has to be in the file. If a change appears to have no effect, check that you edited the file that is actually mounted, and that you restarted the components afterwards.
How the file is used
All three components share this one file and each reads the keys it needs. Core reads the platform connection and the license, ingestion reads the queue settings, and worker reads the concurrency settings and your sources. A key that a given component does not use is simply ignored by it.
The default path is ./config.yml, and --config points somewhere else. The container images already pass --config /etc/vaurd/config.yml.
Keys you leave out fall back to the defaults listed below, so a short file is fine. There is no need to restate a value just to keep it.
Identity and transport
These sit at the top level of the file.
app: vaurd-agent port: 5001 license: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9...
About the three TLS keys. They encrypt traffic between the agent's own components, not the connection to Vaurd. server_cert and server_key must be set together: if either is missing, the agent's gRPC servers fall back to plaintext and log that they are running without TLS.
The agent itself treats all three as optional, which is why the defaults above are empty. In practice you will already have them, because the configuration file the platform generates during registration arrives with the certificates filled in. Carry them across as they are rather than generating your own.
Setting ca_cert on its own makes the other components attempt TLS against servers that are serving plaintext, and every one of them fails to start. Either provide all three keys or leave all three out.
Connecting to Vaurd
The vaurd section covers everything about the agent's relationship with the platform.
vaurd:
manager_url: am.vaurd.com:5000
ping_interval_seconds: 5
status_guard_poll_seconds: 5
ca_cert: |
-----BEGIN CERTIFICATE-----
<vaurd platform CA certificate>
-----END CERTIFICATE-----Lowering ping_interval_seconds makes a dropped agent show as disconnected sooner, at the cost of more chatter. The default suits almost everyone.
Storage and internal addresses
The services section tells each process where to find the shared volume and the other components.
services.storage
The database is created at <data_dir>/vaurd.db and plugin binaries land in <data_dir>/.plugins. All three components must point at the same directory on the same shared volume, because they open the same database file. Relative paths resolve against each process's working directory, so in any container deployment set this to the absolute mount path.
services.nats
These credentials must match the ones the NATS server itself was started with.
services.core
Ingestion and worker both call core at start-up to fetch the database encryption key, so neither can start without this.
services:
storage:
data_dir: /data
nats:
endpoint: nats://nats:4222
username: natsuser
password: natspassword
core:
address: core:5001
server_name: vaurd-agentPlugins
Plugins are the binaries that let the agent talk to a particular kind of source. The platform sends them down during registration.
plugins:
- name: database_postgres
version: latestYou rarely need this section. The agent works out which source plugins it needs from your sources entries and downloads those automatically, and the flow scheduler plugin is always installed whether you list it or not. Use it when you want to pin a specific version rather than track the latest.
Flow execution
The evaluator section controls how the worker runs flows.
evaluator: max_concurrency: 10 max_delivery_attempts: 3
Raise max_concurrency if workers are idle while the queue backs up, but keep an eye on your source systems, since more parallel flows means more simultaneous database connections.
max_delivery_attempts is the safety net for a flow that keeps failing. Without a cap, a broken flow would re-fire its action nodes on every redelivery until the message aged out.
Flow scheduling
When a flow takes its delay from a value in the event payload, this caps how long it can be held. Anything above the ceiling is clamped to it, and a value of zero or less in the config falls back to the default of 24 hours. It stops a malformed payload from parking a flow indefinitely.
Telemetry
Controls how execution results are batched and shipped back to Vaurd. Every key is independent.
telemetry: batch_size: 100 batch_wait_ms: 5000 stream_ttl_seconds: 60 max_bytes: 1073741824
These settings change timing and buffering only. They do not change what is sent. For what telemetry contains, and the guarantee that fetched rows are never part of it, see What leaves your network.
Data sources
The sources section is the one you always edit yourself. Each entry is one connection the agent can read from, and you can list as many as you need.
Two types are supported today:
sources:
- name: orders_db
type: database_postgres
params:
host: db.internal
port: 5432
user: vaurd
password: <password>
database: orders
- name: inventory_db
type: database_mysql
params:
host: mysql.internal
port: 3306
user: vaurd
password: <password>
database: inventoryThe agent works out which plugins it needs from the types you list here and downloads them itself, so adding a type you have not used before takes a moment longer on the next start.
For what goes under params for each type, see Data source parameters.
A flow's fetch node refers to a source by its technical name. If the name here does not match the source you created in the web application, flows using it fail at run time with the source not found.
These credentials stay in this file, inside your environment. They are never sent to Vaurd. See Source systems.
Updating your sources
Adding a database, rotating a password or moving a host all follow the same three steps.
Step 1. Edit the sources section of config.yml.
Step 2. Restart the agent components so they pick up the change:
# Docker docker compose restart core ingestion worker # Kubernetes, with the raw manifests kubectl -n vaurd rollout restart deploy/vaurd-agent-core \ deploy/vaurd-agent-ingestion deploy/vaurd-agent-worker
With Helm, change your values file and run helm upgrade. The pods roll automatically.
Step 3. Confirm the source appears on the agent's details screen in Configure → Agents, under its Sources tab.
If you added a source of a type the agent has not used before, core downloads that plugin on start-up, so give it a moment before testing a flow.
A complete example
app: vaurd-agent
port: 5001
license: eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9...
vaurd:
manager_url: am.vaurd.com:5000
ping_interval_seconds: 5
status_guard_poll_seconds: 5
ca_cert: |
-----BEGIN CERTIFICATE-----
<vaurd platform CA certificate>
-----END CERTIFICATE-----
services:
storage:
data_dir: /data
nats:
endpoint: nats://nats:4222
username: natsuser
password: natspassword
core:
address: core:5001
server_name: vaurd-agent
evaluator:
max_concurrency: 10
max_delivery_attempts: 3
telemetry:
batch_size: 100
batch_wait_ms: 5000
sources:
- name: orders_db
type: database_postgres
params:
host: db.internal
port: 5432
user: vaurd
password: <password>
database: orders