Caddy

Caddy handles public HTTP/HTTPS ingress on the Rocky Linux host. Keeping it outside K3s preserves certificate handling, reverse-proxy recovery, and the static site when the cluster is unavailable.

Custom DNS build

The standard package supplies Rocky Linux service integration, but DNS-01 certificate issuance requires a third-party Namecheap DNS module. Replacing the package-owned binary would allow a later RPM update to overwrite the custom build without making the loss of the module obvious.

The RPM therefore retains ownership of the service account, unit scaffolding, and filesystem integration. The xcaddy build lives separately under /usr/local/bin, and a systemd drop-in replaces the packaged start, validation, and reload commands while loading a root-protected environment file. Installation is accepted only after the binary's module list contains the required provider.

SELinux is part of that installation contract. A binary copied to /usr/local/bin does not automatically receive the HTTP server executable type, so a persistent file-context rule assigns httpd_exec_t and relabeling applies it. Disabling SELinux would conceal the packaging error and weaken unrelated boundaries.

Caddy RPM -> user, unit, support paths
custom binary -> required DNS provider module
systemd drop-in -> custom binary + private environment
SELinux fcontext -> httpd_exec_t
absolute access logs -> CrowdSec

Change and failure boundaries

Configuration changes are validated before installation, existing live files are backed up before replacement, and the effective service path is checked after systemd reload and restart. External HTTPS checks cover more than a syntactically valid Caddyfile: they also exercise listener, certificate, DNS, routing, and upstream behavior.

A successful version check does not prove that the DNS module is present or that systemd starts the intended binary. Every Caddy or xcaddy upgrade therefore rechecks the module list, configuration, SELinux label, effective unit, listeners, and external routes.

Structured access logs are consumed by CrowdSec. The log file, acquisition pipeline, decision engine, and firewall enforcement remain independently verifiable layers.