How-to guide

Install Signals

Get the Signals daemon and the signalsctl CLI onto your host or cluster. Pick the install path that fits your environment — the Docker image is the quickest way to get a daemon running, release binaries suit host installs, and Helm is for Kubernetes.

Signals monitors PostgreSQL 14 or newer. Choose one of the options below, then verify the install before moving on to configuration.

Docker

The image bundles both binaries and runs the daemon as its entrypoint. Mount your config at /etc/signals/signals.yaml and a volume for the snapshot store at /data.

docker run -d --name signals \
  -v "$PWD/signals.yaml:/etc/signals/signals.yaml:ro" \
  -v signals-data:/data \
  -p 127.0.0.1:8081:8081 \
  ghcr.io/elevarq/signals:<version>

Replace <version> with a tag from the releases page and use the matching GHCR image tag. Pin a concrete tag (for example, 0.10.0-rc.1) instead of assuming latest exists. Release names may include a leading v, while image tags can omit it, so confirm the tag with docker pull before using it in a script. For the published port to be reachable, the mounted config must bind the API on 0.0.0.0:8081 (the -p 127.0.0.1:8081:8081 mapping keeps it on host loopback) — see the tutorial and configuration reference.

Pre-built binaries

Each GitHub release publishes signals-<os>-<arch> and signalsctl-<os>-<arch> for linux/darwin × amd64/arm64. Substitute the latest version and your platform:

base="https://github.com/Elevarq/Signals/releases/download/<version>"
curl -fsSL -o signals     "$base/signals-linux-amd64"
curl -fsSL -o signalsctl  "$base/signalsctl-linux-amd64"
chmod +x signals signalsctl
sudo mv signals signalsctl /usr/local/bin/

Build from source

Building from source needs Go 1.26 or newer.

git clone https://github.com/Elevarq/Signals.git
cd Signals
make build          # produces bin/signals and bin/signalsctl

Kubernetes (Helm)

Install the chart from the OCI registry, pointing at your own values.yaml:

helm install signals oci://ghcr.io/elevarq/charts/signals \
  --version <version> -f values.yaml

A minimal values.yaml sets a single target. To monitor several databases from one install, add a targets list — each entry is rendered alongside the single target, so one collector covers them all:

# values.yaml — one Signals install, multiple databases
target:
  host: primary.example.com
  authMethod: aws_rds_iam        # passwordless cloud auth
  sslmode: verify-full
  sslRootCertFile: /etc/signals/server-ca.crt

targets:
  - name: replica
    host: replica.example.com
    authMethod: aws_rds_iam
    sslmode: verify-full
    sslRootCertFile: /etc/signals/server-ca.crt
  - name: analytics
    host: analytics.example.com
    authMethod: secret_store
    sslmode: verify-full
    secretRef: <cloud-vault-reference>

persistence:
  storageClass: <your-storage-class>

name and host are required per entry; port, dbname, user, and sslmode default to 5432, postgres, signals, and prefer. Only paths, cloud references, and env-var names ever go in values.yaml — never credentials. Multiple-database chart support needs a recent Signals chart; see Configure authentication and the configuration reference for the full field list and per-target auth methods.

Verify

Confirm the CLI is on your path and reports a version:

signalsctl version

Next, grant Signals the read-only database access it needs and configure how it connects: Create the monitoring role and Configure authentication.