One systemd unit per role, on as many hosts as you have, sharing one log server. This is the shape Choose your deployment points at for systemd split by role. Topologies, section 2.2, is the mechanism.

1. Prerequisites

A Debian, Ubuntu, Fedora or RHEL host per role you run (or several roles per host, each under its own unit), plus one more host for the log server. Root access on each.

2. Install

curl -fsSL https://pkgs.jaque.sh/install.sh | sh

on every host that runs a jaque role. See Install for the apt/dnf repositories by hand. The package installs jaque.service, which these units replace one per role; leave jaque.service itself disabled on these hosts.

3. The log server

Pick one host and run a log server on it before starting any role. The log service in split by role, compose names the exact software and version this guide assumes; install your distribution's equivalent package, listening on 4222 reachable from every other host in this guide.

4. The files

The canonical copy of every unit and env file below is under deploy/systemd/distributed/ in the repository: one jaque-<role>.service per role, modelled on the packaged jaque.service (same user, same hardening, its own StateDirectory), and one env file per role under deploy/systemd/distributed/env/. Copy the unit for each role onto the host that runs it, and its env file to /etc/default/jaque-<role> there; replace log.internal with your log server's address.

# deploy/systemd/distributed/jaque-engine.service
[Unit]
Description=jaque monitoring engine (engine role)
Documentation=https://jaque.sh/docs/
After=network-online.target
Wants=network-online.target

[Service]
User=jaque
Group=jaque
EnvironmentFile=/etc/default/jaque-engine
ExecStart=/usr/bin/jaque
Restart=on-failure
RestartSec=5s
StateDirectory=jaque-engine
StateDirectoryMode=0750
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
RestrictSUIDSGID=yes

[Install]
WantedBy=multi-user.target

# deploy/systemd/distributed/env/jaque-engine.env
JAQUE_TARGET=engine
JAQUE_CONFIG=/etc/jaque/config.cue
JAQUE_LISTEN=127.0.0.1:8080
JAQUE_EVENTLOG=nats://log.internal:4222
JAQUE_COORDINATION=nats://log.internal:4222
JAQUE_QUEUE=nats://log.internal:4222
JAQUE_NOTIFY_DELIVERY=external

The worker, ui, notifier and sink units are the same shape with their own StateDirectory and env file; worker takes no -config and ui listens on 0.0.0.0 since it serves the dashboard. engine runs -notify-delivery external because a notifier unit is also running.

5. Start

On each host, after copying its unit and env file:

systemctl daemon-reload
systemctl enable --now jaque-<role>

6. Verify

jaque version
curl http://<ui-host>:8080/status.json

on the ui host, and curl http://127.0.0.1:8080/metrics | grep jaque_membership_size on the engine host -- with one engine, the value is 1.

7. Add a worker zone

Copy jaque-worker.service and its env file to another host, set JAQUE_ZONES in that copy to the new zone name, and give the hosts in your config that zone. Only a worker serving a zone picks up checks for objects in it; see Topologies, section 3.

8. Where things live

Config at /etc/jaque/config.cue on every host that takes -config (every role but worker). Environment per role at /etc/default/jaque-<role>. State under /var/lib/jaque-<role>, one directory per role. Logs go to each unit's journal: journalctl -u jaque-<role>.

9. Upgrade

apt-get update && apt-get install -y jaque   # Debian/Ubuntu
dnf upgrade -y jaque                          # Fedora/RHEL

on each host, then systemctl restart jaque-<role> there. Roles on different hosts upgrade independently; nothing requires taking the whole deployment down at once.

10. Next steps

CUE in practice adds services and contacts to the shared config. Contacts and policies wires a hard state to a person, delivered by the notifier role. Cluster and coordination is what adding a second engine host buys.

11. Security considerations

worker holds no config and no notification secret; sink and notifier open no dashboard, API or Livestatus listener. See Cluster and coordination, section 7, for what access to the log server amounts to, and Security for the rest.