Caddy 2.11

Apply these rules when configuring Caddy 2.11 as an HTTPS server, reverse proxy, or PHP gateway. This scope covers the standard distribution and its configuration; third-party modules and application code need their own review.

1. Supported builds and trusted configuration

• Run the newest stable Caddy release that receives security fixes; the project supports the latest minor, not every older minor of a major. Let a trusted package source or line-following image tag select the patch, look up the current release, never loosen an existing constraint to make an installation succeed, and audit dependencies and images in CI. Check the running Caddy binary, its Go runtime, and loaded modules separately from application package audits.
• Treat Caddyfiles, JSON configuration, imports, environment substitutions, provisioning hooks, and configuration adapters as privileged code. Keep them outside uploaded or tenant-writable trees; never build configuration by interpolating request content.
• Install only reviewed modules from trusted sources. Keep the exact module inventory and build inputs available for maintenance; a module runs with the server's privileges and is not an isolation boundary.
• Run as a dedicated operating-system identity with only the required bind capabilities, read access to deployed content, and write access to its own state and logs. Separate mutually untrusted applications and their keys into different processes or containers.
• Validate the adapted configuration with caddy validate before a controlled reload. Verify the effective JSON, listener