The Argo Watcher server supports the following environment variables. When using the Helm chart, most of these are set through chart values automatically.
On startup, any missing required or invalid variables are reported together in a single error that lists every offending variable, so you can fix them all in one pass instead of one restart at a time.
These variables are required when using the built-in GitOps updater. See the GitOps Updater guide for full details.
Variable
Description
Default
Required
SSH_KEY_PATH
Path to the SSH key for Git repository access
Conditional
SSH_KEY_PASS
Passphrase for the SSH key
No
SSH_COMMIT_USER
Git commit author name
argo-watcher
No
SSH_COMMIT_MAIL
Git commit author email
argo-watcher@example.com
No
COMMIT_MESSAGE_FORMAT
Go template string for commit messages
No
GIT_OP_TIMEOUT
Per-attempt wall-clock budget for one clone + update cycle. The worst-case total wall clock for the full retry loop is GIT_OP_TIMEOUT × GIT_MAX_ATTEMPTS, plus a small jittered backoff between attempts (capped-exponential, starting near 250ms and never exceeding 2s per retry — early retries fire fast to win a git push race under contention). Accepts a Go duration string (e.g. 30s, 2m). Must be greater than zero.
90s
No
GIT_MAX_ATTEMPTS
Total attempts (initial + retries) before giving up on a git update. The final attempt invalidates the on-disk cache and performs a fresh clone, so a poisoned cache self-heals without operator intervention. Raising this hardens the write-back against a competing writer on a shared repo; a task superseded by a newer deployment for the same app aborts its write-back (re-checked before every attempt) instead of committing a stale tag, so a larger value does not let an older deployment overwrite a newer one. Must be greater than zero.
5
No
GIT_TIMEOUT
Deprecated. Legacy per-call budget. When set and GIT_OP_TIMEOUT is unset, the value is used directly as GIT_OP_TIMEOUT (1:1 mapping, preserving the original per-call budget). Set GIT_OP_TIMEOUT explicitly to silence the deprecation warning.
—
No
GIT_BATCH_WRITEBACK
Opt-in batch write-back mode. When enabled, concurrent write-backs to the same repository are coalesced into a single clone and push instead of each taking the per-repo lock on its own, collapsing the tail latency seen when many apps deploy to one GitOps repo at once. Off by default; the serialized per-app path is unchanged when disabled. See the GitOps Updater guide.
false
No
GIT_BATCH_MAX_SIZE
Maximum number of applications committed in a single batch flush (one commit per app, then one push). Only meaningful when GIT_BATCH_WRITEBACK is enabled, where it must be greater than zero. The pending queue keeps accumulating across flushes until drained, so this bounds one flush, not total in-flight work.