Improve Caddy Salt state: pillarize hostnames, graceful reload, Jinja parameterization #440

New issue

Closed

opened 2026-06-15 23:51:19 +00:00 by ldraney · 0 comments

ldraney commented

2026-06-15 23:51:19 +00:00

Owner

Type

Feature

Lineage

Related to ldraney/pal-e-platform #425 (Caddy Salt state for palinks.app reverse proxy, PR #439). Prepares for multi-domain support in #434.

Repo

ldraney/pal-e-platform

User Story

As a platform operator
I want the Caddy Salt state to be data-driven and use graceful reloads
So that adding new domains requires only pillar changes and config updates cause zero downtime

Context

PR #439 introduced salt/states/caddy/init.sls and salt/states/caddy/Caddyfile.j2 for the palinks.app reverse proxy. The implementation works but has three quality improvements needed before adding more domains (#434):

The Tailscale domain suffix (tail5b443a.ts.net) is hardcoded in the Caddyfile template
The Salt state uses service.running with watch, which does a full Caddy restart instead of graceful reload
The Caddyfile template is not parameterized -- adding a domain means editing the template rather than just adding pillar data

File Targets

Files the agent should modify:

salt/states/caddy/init.sls -- replace service restart with caddy reload, adjust state structure
salt/states/caddy/Caddyfile.j2 -- add Jinja loops over pillar-defined sites, remove hardcoded hostnames

Files the agent should NOT touch:

Salt pillar files -- pillar structure will be documented in the PR but not created here

Feature Flag

none

Acceptance Criteria

Tailscale domain suffix is no longer hardcoded in the Caddyfile template
Salt state uses caddy reload --config /etc/caddy/Caddyfile with onchanges instead of service.running with watch
Caddyfile.j2 uses Jinja loops over pillar['caddy']['sites'] to generate site blocks
Adding a new domain (e.g. landscaping-assistant.app) requires only pillar data changes, no template edits

Test Expectations

Manual review: rendered Caddyfile output matches expected format for palinks.app
Manual review: Salt state structure is valid SLS syntax
Run command: visual inspection of Jinja template rendering

Constraints

Must stack on top of PR #439 (branch 425-caddy-palinks-app)
Follow existing Salt state patterns in the repo
Pillar structure should be documented in PR body but pillar files are not created in this PR

Checklist

PR opened
No unrelated changes

pal-e-platform -- infrastructure project

### Type Feature ### Lineage Related to `ldraney/pal-e-platform #425` (Caddy Salt state for palinks.app reverse proxy, PR #439). Prepares for multi-domain support in #434. ### Repo `ldraney/pal-e-platform` ### User Story As a platform operator I want the Caddy Salt state to be data-driven and use graceful reloads So that adding new domains requires only pillar changes and config updates cause zero downtime ### Context PR #439 introduced `salt/states/caddy/init.sls` and `salt/states/caddy/Caddyfile.j2` for the palinks.app reverse proxy. The implementation works but has three quality improvements needed before adding more domains (#434): 1. The Tailscale domain suffix (`tail5b443a.ts.net`) is hardcoded in the Caddyfile template 2. The Salt state uses `service.running` with watch, which does a full Caddy restart instead of graceful reload 3. The Caddyfile template is not parameterized -- adding a domain means editing the template rather than just adding pillar data ### File Targets Files the agent should modify: - `salt/states/caddy/init.sls` -- replace service restart with `caddy reload`, adjust state structure - `salt/states/caddy/Caddyfile.j2` -- add Jinja loops over pillar-defined sites, remove hardcoded hostnames Files the agent should NOT touch: - Salt pillar files -- pillar structure will be documented in the PR but not created here ### Feature Flag none ### Acceptance Criteria - [ ] Tailscale domain suffix is no longer hardcoded in the Caddyfile template - [ ] Salt state uses `caddy reload --config /etc/caddy/Caddyfile` with `onchanges` instead of `service.running` with watch - [ ] Caddyfile.j2 uses Jinja loops over `pillar['caddy']['sites']` to generate site blocks - [ ] Adding a new domain (e.g. landscaping-assistant.app) requires only pillar data changes, no template edits ### Test Expectations - [ ] Manual review: rendered Caddyfile output matches expected format for palinks.app - [ ] Manual review: Salt state structure is valid SLS syntax - Run command: visual inspection of Jinja template rendering ### Constraints - Must stack on top of PR #439 (branch `425-caddy-palinks-app`) - Follow existing Salt state patterns in the repo - Pillar structure should be documented in PR body but pillar files are not created in this PR ### Checklist - [ ] PR opened - [ ] No unrelated changes ### Related - `pal-e-platform` -- infrastructure project