Hostnames and TLS
Hosting Caddy on each managed server listens on :80 and :443. A hostname
you pin to a service can use an uploaded or self-signed library certificate,
Caddy tls internal, or a Let's Encrypt library row that Caddy issues and
renews on the host (tlsMode: acme).
Let's Encrypt (managed by Caddy)
A Let's Encrypt certificate in the organization TLS library is intent only until Caddy obtains the leaf. HTTP-01 is the only challenge. That requires:
- The hostname resolves to the serving host (the daemon that will run the site).
- :80 and :443 are reachable from the internet on that host.
- No wildcard names (
*.example.com). Request each hostname explicitly. - The hosting bind scope must be public.
localanddatacenterbinds cannot receive HTTP-01 traffic; deploy-prepare refuses those pins withacme_requires_public_bind.
Caddy writes and renews the certificate on the host. TurboPanel does not run its own ACME client. Wildcards and DNS-01 are rejected when the library row is created.
See also Organization CA — hosting leaves are never issued by the Organization CA.
Last updated on
Network addressing
Reserved ranges and Docker address pools, worked against a multi-NIC fleet with two datacenters, a corporate VPN allocation, and dockerd pools moved off it
License tiers
The S1–S7/SX ladder on TurboPanel High Availability — how a server is placed, what a tier watches, what happens when a machine outgrows its license, and why self-hosted buys none of it