Deploying the agent
The agent ships as a set of container images. Run them with Docker on a single host, or on a Kubernetes cluster.
The agent is configured entirely from a config.yml that the Vaurd platform generates for you, and it needs a license key that the platform issues. Both come from the first three steps of Registering an agent. Do those first, then come back here.
What you are deploying
Three container images, plus a NATS server that connects them.
Worker exposes nothing of its own. It takes flows off the queue and connects out to your source systems, so nothing ever needs to reach it. Core and ingestion are the two that accept connections.
What they share
One volume, mounted at `/data` by all three components. It holds the agent's encrypted database, vaurd.db, and the plugin binaries the platform downloads during registration. All three components open the same database file, so this volume has to be writable by all of them at once. On Kubernetes that means a ReadWriteMany storage class.
One configuration file, mounted at `/etc/vaurd/config.yml` in all three components. Every process reads its settings from this one file. Environment variables are ignored, so anything you need to change belongs in the file. See Agent configuration.
Start-up order
Core has to be running before the others become useful. At start-up, ingestion and worker both call core over gRPC to get the key that unlocks the shared database. Until core is up and registered, they cannot open it.
This is normal and self-correcting: on a first install you will see ingestion and worker restart once or twice while they wait for core. They settle on their own.
To check core directly rather than inferring it from the other two, ask it for its health over gRPC. It answers the standard health check, so grpcurl -cacert <(yq -r '.ca_cert' config.yml) <core-host>:5001 grpc.health.v1.Health/Check returns SERVING once it is up. The deployment pages below show the exact command for each method.
Network access
Ingestion only needs to be reachable from wherever your events are produced. If that is inside the same network, it never has to be public.
Choosing a method
Both produce the same architecture and the same config.yml. Pick whichever matches where you already run things.
- Docker deployment: a single compose file that runs all four containers on one host.
- Kubernetes deployment: a published Helm chart, or plain YAML manifests.