Topologies

One binary, six roles. Every deployment shape below is the same jaque executable started with a different -target — nothing to build separately, nothing to install differently per role.

The six targets

all (default)

Schedules and executes checks in the same process. Requires -config. Forbids -queue (nothing to dispatch checks to) and -notifier-id (there’s no separate notifier identity to name).

engine

Decides what and when, but never runs a check itself — it publishes each one to -queue and waits for the result. Requires -config and -queue. Forbids -notifier-id.

worker

No config, no event log, no projection — it only pulls work items from -queue and executes them. Requires -queue; forbids -config, -coordination, -heartbeat-ttl, and every notification flag. Needs its own disk: any legacy plugin or WASM module a remote check uses must be installed on the worker’s machine, not the engine’s.

ui

Read-only: follows the event log and serves the dashboard/API, never schedules or runs a check, never handles SIGHUP. Requires -config (for labels, views, the dependency graph). Forbids -queue, -command-file, -events-out, -sink, -archive, both -livestatus-* flags, -heartbeat-ttl, and every notification flag. With -coordination pointed at the shared store, commands it receives are forwarded to the engine fleet (jaque.work.cmd.ingress) fire-and-forget; without it, writes are rejected with 503. -target ui never joins engine membership.

sink

Only perfdata (metrics-input) sinks, on its own sink/membership/ bucket and a -sink-id (hostname by default). Requires -config. Forbids -queue, -command-file, -events-out, -archive, both -livestatus-* flags, -snapshot-out, -api-token, every SMTP/Telegram flag, and every notification flag — none of that surface exists in this role. -sinks selects which of the CUE config’s sinks: block this process runs; empty runs all of them. A sink declared with input: "events" is rejected for this target — no events-input sink runs under -target sink. This role does not reconcile its sink set on SIGHUP: restart the process to pick up an added, removed, or changed sink.

notifier

Only notification delivery, on its own notifier/membership/ bucket (sibling to membership/ and sink/membership/, not nested under either) and a -notifier-id. Requires -config (contacts and policies live there). Forbids -queue, -sink, -archive, -command-file, -events-out, -snapshot-out, both -livestatus-* flags, -api-token, and -notify-delivery (that flag belongs to all/engine, which decide where delivery happens — not to the notifier that is the delivery target). Accepts -smtp-*, -telegram-token, -notify-workers, -notify-queue.

Two decisions, three shapes

Every deployment sits somewhere on two independent axes: how many processes (one -target all, or one process per role) and how many engines (one, or several sharing ownership of the object set). The two axes compose — production is usually both split by role and running more than one engine. The three shapes below are the useful corners of that grid, not three rungs of a ladder.

(a) Standalone

Everything in one process. See Overview for when this is enough.

(b) Split by role

Every role points -eventlog and -coordination at the same external JetStream. engine dispatches work over -queue nats://...; one or more worker processes pull it, scoped by -zones (see below). ui, sink, and notifier each follow the log independently, each scaling on its own membership bucket.

Splitting by role buys scale for worker/ui/sink/notifier and network isolation between them. It does not buy availability of the check loop itself: there is still exactly one engine process, and if it dies checks stop until it comes back. (c) is the second axis that fixes that — the two combine.

(c) Multiple engines

This is (b)’s second axis, not a replacement for it: the same role split, with more than one engine process instead of one. See Cluster and coordination for how membership, rendezvous-hashed ownership, heartbeats and epoch fencing combine to make that safe.

Worker zones

-zones (default default, comma-separated) is which zones a worker serves. Each host in CUE carries a zone (default "default"); each service inherits its host’s zone unless it sets its own. The engine publishes each check to its object’s zone’s queue; only a worker subscribed to that zone picks it up — the mechanism for routing checks to workers that can actually reach a given network segment.

The remote agent: not yet

A future outbound-gRPC, mTLS remote agent is planned (roadmap phase 7) for sites where even the pull-based worker model doesn’t fit — it does not exist yet. Today, cross-network execution is the engine/worker split above, over a queue both sides can reach.