public mail vpn: reload caddy on a Caddyfile change instead of restarting it (nix-config#926) #1960

Merged

hermes merged 1 commit from kb/NCFG-926-caddy-reload into main 2026-10-13 05:27:39 -06:00

Conversation 0 Commits 1 Files changed 3 +21 -3

hermes commented 2026-10-13 05:22:01 -06:00

Collaborator

Copy link

Card: nix-config#926 (board https://board.ymrtech.com)

What

services.caddy.enableReload = false on public, mail and vpn -> true.

With false, the nixpkgs caddy module puts the rendered Caddyfile in
restartTriggers, so any Caddyfile change (vhost, route, cert line, log format)
is a full systemctl restart caddy = whole-site outage. Measured on public:
56 restarts in 7 days, 4-15 s each (VictoriaLogs UNIT:"caddy.service" AND (_msg:"Stopping" OR _msg:"Started")).

With true the Caddyfile moves to reloadTriggers and the module adds
ExecReload = caddy reload --config /etc/caddy/caddy_config --adapter caddyfile --force,
which is graceful: the old process keeps serving until the new config is applied.
true is the nixpkgs module default; vpn-mx never overrode it, so these three
hosts were the odd ones out. All three already configure the loopback admin API
the reload path needs (admin localhost:2019 in globalConfig).

Evidence (evaluated from this branch)

For each of public, mail and vpn, systemd.services.caddy now reads:

ExecReload    = ["", "...caddy reload --config /etc/caddy/caddy_config --adapter caddyfile --force"]
reloadTriggers  = 1 entry
restartTriggers = 0 entries

and each host's system.build.toplevel.drvPath evaluates.

X-Reload-Triggers is handled by the rust switch-to-configuration shipped in
the pinned nixpkgs (rev 7b66dac): it prints would reload the following units:.

Note on the live check

The switch that MOVES the config from restart to reload triggers also changes the
unit definition, so it can still restart caddy once - that transition is
unavoidable. The DoD's "a deploy that changes the Caddyfile reloads" is therefore
verified with a second, config-content-only deploy on public (PR2), which changes
nothing but the Caddyfile.

Card: nix-config#926 (board https://board.ymrtech.com) ## What `services.caddy.enableReload = false` on public, mail and vpn -> `true`. With `false`, the nixpkgs caddy module puts the rendered Caddyfile in `restartTriggers`, so *any* Caddyfile change (vhost, route, cert line, log format) is a full `systemctl restart caddy` = whole-site outage. Measured on public: 56 restarts in 7 days, 4-15 s each (VictoriaLogs `UNIT:"caddy.service" AND (_msg:"Stopping" OR _msg:"Started")`). With `true` the Caddyfile moves to `reloadTriggers` and the module adds `ExecReload = caddy reload --config /etc/caddy/caddy_config --adapter caddyfile --force`, which is graceful: the old process keeps serving until the new config is applied. `true` is the nixpkgs module default; `vpn-mx` never overrode it, so these three hosts were the odd ones out. All three already configure the loopback admin API the reload path needs (`admin localhost:2019` in `globalConfig`). ## Evidence (evaluated from this branch) For each of public, mail and vpn, `systemd.services.caddy` now reads: ExecReload = ["", "...caddy reload --config /etc/caddy/caddy_config --adapter caddyfile --force"] reloadTriggers = 1 entry restartTriggers = 0 entries and each host's `system.build.toplevel.drvPath` evaluates. `X-Reload-Triggers` is handled by the rust `switch-to-configuration` shipped in the pinned nixpkgs (rev 7b66dac): it prints `would reload the following units:`. ## Note on the live check The switch that MOVES the config from restart to reload triggers also changes the unit definition, so it can still restart caddy once - that transition is unavoidable. The DoD's "a deploy that changes the Caddyfile reloads" is therefore verified with a second, config-content-only deploy on public (PR2), which changes nothing but the Caddyfile.

hermes added 1 commit 2026-10-13 05:22:01 -06:00

public mail vpn: reload caddy on a Caddyfile change instead of restarting it ... 345cb952b2

services.caddy.enableReload was false on public, mail and vpn, so the nixpkgs
caddy module put the rendered Caddyfile in restartTriggers: every deploy that
touched a vhost, route, cert or log line did a full caddy restart, i.e. a
whole-site outage. Measured on public: 56 restarts in 7 days, 4-15 s each.

Set enableReload = true (the module default; vpn-mx never overrode it), so the
Caddyfile moves to reloadTriggers and ExecReload runs "caddy reload --config
/etc/caddy/caddy_config --adapter caddyfile --force", which needs the loopback
admin API all three hosts already configure (admin localhost:2019).

hermes merged commit 57746cc4b7 into main 2026-10-13 05:27:39 -06:00

hermes referenced this pull request from a commit 2026-10-13 05:27:41 -06:00

Merge pull request 'public mail vpn: reload caddy on a Caddyfile change instead of restarting it (nix-config#926)' (#1960) from kb/NCFG-926-caddy-reload into main

hermes referenced this pull request 2026-10-13 05:49:05 -06:00

public: document that a Caddyfile change reloads caddy (verification for nix-config#926) #1963

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

backlog

  

bug

  

enhancement

  

in-progress

  

review

  

todo

No labels

backlog

bug

enhancement

in-progress

review

todo

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ymrtech/nix-config!1960

No description provided.