counterweight
fba533ebb1
Relinking after the rebuild failed: the phone said "network error" and signal-cli logged "Link request error: Connection closed!", with the network itself fine (TLS to chat.signal.org completed). The pinned 0.100 bundled signal-cli 0.14.5 from June; Signal stops accepting clients that fall a few months behind. 0.101 (signal-cli 0.14.8) linked first time. A stale pin fails the same way for alerts - silently - so the pin now carries signal_api_version beside the digest and a note to bump it every couple of months. The old comment saying upstream publishes no versioned tags was wrong. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
46 lines
2.4 KiB
YAML
46 lines
2.4 KiB
YAML
---
|
|
# signal-cli-rest-api: the transport Gatus uses to send Signal messages.
|
|
#
|
|
# Gatus does not speak Signal. It POSTs JSON to this service, which holds the
|
|
# actual Signal identity and does the protocol work.
|
|
|
|
# Pinned by DIGEST, with the release tag alongside for humans - same as Gatus.
|
|
# A tag is mutable; a digest is a content address, so `docker compose pull`
|
|
# either fetches exactly this image or fails. Upstream publishes versioned
|
|
# release tags (0.97 ... 0.101); the two values below must move together.
|
|
#
|
|
# THIS PIN EXPIRES. Signal's servers stop accepting signal-cli releases that
|
|
# fall a few months behind. 0.100 (signal-cli 0.14.5, 2026-06-11) was refused
|
|
# on 2026-10-18 - the phone reported "network error" and signal-cli logged
|
|
# "Link request error: Connection closed!", with the network itself fine. A
|
|
# stale pin fails exactly the same way for ALERTS: silently. Bump this at least
|
|
# every couple of months: https://github.com/bbernhard/signal-cli-rest-api/releases
|
|
signal_api_version: "0.101" # bundles signal-cli 0.14.8
|
|
signal_api_image_digest: "sha256:2cf09d66a86fdd210e42ee91662216364acc27da1163a8c44167a77ea3a6559a"
|
|
signal_api_image: "bbernhard/signal-cli-rest-api@{{ signal_api_image_digest }}"
|
|
|
|
signal_api_dir: /opt/signal-api
|
|
signal_api_data_dir: "{{ signal_api_dir }}/data"
|
|
|
|
# MODE matters on this host. Upstream offers normal / native / json-rpc /
|
|
# json-rpc-native. json-rpc keeps a resident JVM daemon and upstream describes it
|
|
# as "increased memory" - this VPS has 464MB total and already runs Gatus and
|
|
# Caddy, so a resident JVM is not affordable. `native` runs a precompiled
|
|
# GraalVM binary per request: no daemon, no resident cost, and alerts are rare
|
|
# enough that paying startup per alert is the right trade.
|
|
signal_api_mode: native
|
|
|
|
# Port INSIDE the shared docker network. Never published to the host: this API
|
|
# has NO AUTHENTICATION of any kind. Anyone who can reach it can send messages
|
|
# as you and read your Signal.
|
|
signal_api_port: 8080
|
|
|
|
# Both this and Gatus join this network so Gatus can reach the API by service
|
|
# name. Gatus runs in a container, so the host's loopback is NOT reachable from
|
|
# it - this is why a shared network is required rather than a published port.
|
|
signal_api_network: monitoring
|
|
signal_api_service_name: signal-api
|
|
|
|
# The uid the upstream image drops to (`setpriv --reuid=1000`). The data
|
|
# directory must be owned by it or signal-cli cannot write the account.
|
|
signal_api_uid: 1000
|