Linux, standalone (no Docker)

This is the layout the installer creates with --native: two standalone binaries running as systemd units, vectorstep and vectorstep-gateway. (On a Linux host running the Docker install, see Docker and Docker Compose instead.)

Where things live

	VectorStep	Gateway
Config	`/etc/vectorstep/vectorstep/config.yaml`	`/etc/vectorstep/vectorstep-gateway/config.yaml`
Secrets (`${VAR}` values, tokens)	`/etc/vectorstep/vectorstep/env`	`/etc/vectorstep/vectorstep-gateway/env`
Authored files	`/var/lib/vectorstep/vectorstep/pipelines/`, `…/steps/`	`/var/lib/vectorstep/vectorstep-gateway/agents/`, `…/skills/`
Logs	`/var/log/vectorstep/vectorstep/` and `journalctl -u vectorstep`	`/var/log/vectorstep/vectorstep-gateway/` and `journalctl -u vectorstep-gateway`

The services run as the vectorstep user, so files you add must be readable by it:

sudo cp my-pipeline.yaml /var/lib/vectorstep/vectorstep/pipelines/
sudo chown vectorstep:vectorstep /var/lib/vectorstep/vectorstep/pipelines/my-pipeline.yaml

Change a pipeline, step, agent or skill

Edit or add the file, then reload the service that owns it. Each unit’s reload sends it a SIGHUP, which re-reads the files without stopping the process:

sudo systemctl reload vectorstep            # pipelines, steps
sudo systemctl reload vectorstep-gateway    # agents and skills (one reload covers both)

systemctl reload doesn’t tell you whether the files were accepted, so check the log:

journalctl -u vectorstep -n 20              # "SIGHUP: reloaded N pipeline(s)"

If a file is invalid, the reload is rejected, the reason is logged and the running config is untouched — fix the file and reload again.

If you’d rather get the result back directly, call the API on the service. The admin token is in its env file:

set -a; . <(sudo cat /etc/vectorstep/vectorstep/env); set +a
curl -X POST -H "Authorization: Bearer $VECTORSTEP_ADMIN_TOKEN" http://localhost:8000/reload

Change a shell-step script

Shell-step scripts live in the directory named by security.shell_steps.scripts_dir in the service’s config.yaml. Each needs its execute bit and a pinned sha256 under security.shell_steps.allowed. That list is read once at startup, so a change to a script or its pin takes effect on a restart, not a reload:

sha256sum /path/to/scripts/classify-severity.sh     # update the pin in config.yaml
sudo systemctl restart vectorstep

See Run a shell step for the full setup.

Change `config.yaml` or a secret

Most settings are read at startup, so restart the service that owns the file:

sudo systemctl restart vectorstep           # after editing its config.yaml or env
sudo systemctl restart vectorstep-gateway

The exceptions — pricing:, replay: and security policies on the service — are picked up by a reload, no restart needed. See what reloads and what doesn’t.

Notes

Upgrades don’t touch your files. Re-running the installer replaces the binaries and leaves config and state alone.
Prefer an API over editing files? The write API validates and reloads in one call.