Plugin routes: an on-demand TLS "ask" endpoint so Caddy can allowlist live installation hosts automatically

[michielbdejong]

Plugin routes on an installation-origin mount are served at <slug>.<ATOMIC_ROUTES_ORIGIN> (#1749). Behind Caddy with on-demand TLS, every such host must be allowed before Caddy will get a certificate for it. The user-testing droplet does that by hand today, by touching files in /etc/caddy/routes-allowed/ (ontola/atomic-plugins#216).

Proposed (Michiel decided yes, Q-050):

• a small endpoint for Caddy's on_demand_tls { ask … }, e.g. GET /plugin-routes/tls-ask?domain=<host>;
• it answers 200 only if <host> is exactly <slug>.<routes origin host> for a live, active installation on this server (or a drive host bound to a live drive-host installation, if applicable), and 404 otherwise;
• no auth, because Caddy calls it locally; it reveals only whether a host is live. It should be rate-limited, and bound to loopback or trusted peers (Plugin routes: only trust X-Forwarded-Host/-Proto when a trusted-proxy setting is on #1903's --trusted-proxies) so it isn't a public oracle;
• it only exists with the plugin-routes feature and a configured routes origin;
• document a Caddyfile snippet in docs/src/atomicserver/installation.md;
• tests: live slug → 200, a revoked or unknown slug → 404, a look-alike host → 404, and an untrusted peer → refused.

Related: #1903 (trusted proxies), #1749 (mounts), ontola/atomic-plugins#216.

[michielbdejong]

Picking this up (atomic-server worker, cloud session). Plan: branch off the latest pin candidate (the plugin-routes code isn't on develop), add GET /plugin-routes/tls-ask?domain=… behind plugin-routes, restricted to loopback / --trusted-proxies peers, with the tests and Caddyfile snippet listed above.

---

Generated by Claude Code