1. Caddy version (caddy version):
v2.5.1 h1:bAWwslD1jNeCzDa+jDCNwb8M3UJ2tPa8UZFFzPVmGKs=
2. How I run Caddy:
a. System environment:
Ubuntu 22.04
b. Command:
caddy run 2> error.txt 1> access.txt
c. Service/unit/compose file:
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target
[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
d. My complete Caddyfile or JSON config:
{
email <redacted>
acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
on_demand_tls {
ask http://localhost:5555/check
}
}
https:// {
tls {
on_demand
}
root * /var/www/html
file_server
log {
output stdout
}
}
3. The problem I’m having:
First of all, I would like to mention that I really like working with caddy. The simplicity of the config, as well as the active community, makes it a blast to work with. I am currently evaluating whether caddy is a viable solution to manage TLS for hundreds of thousands of domains. For that, I would like to extend my knowledge of caddy. Many questions have already been answered in previous posts, but for some of the following topics I could not find anything.
Consider the following use case: I would like to manage TLS for 500’000+ domains via caddy. I also have an account with letsencrypt that supports increased rate limits. Ideally, the certificates for the domains should be issued, as well as managed, on-demand. My goal is to make the service as robust and performant as possible within my raised rate limits with letsencrypt
- Are there any best practices that you recommend when managing that many domains? (Features such as the
askendpoint which should be used to make the service more performant and robust). - I know that caddy has an internal rate limit which is set to 10 certificates in 1 minute. In previous posts, you have explained that you include this throttle to avoid flooding the CA with certificate requests. Since I have an account with increased rate limits, is there any way I can change this internal limit to better fit my use case (apart from modifying the source code)? Apart from the rate limits of letsencrypt and the internal ones, is there anything else throttling the performance of caddy that can be improved via the config?
- How exactly does caddy handle a large amount of concurrent requests for certificates? From the logs, I can see that locks are requested whenever caddy must request a new certificate. Here, it would be interesting to know, for example, how many threads are available to take incoming requests and how the overall performance is when handling that many requests simultaneously. (I am currently also testing the performance myself to see how it might scale to a large number of requests. However, it would be cool if someone smarter than me could explain how exactly the inner workings handle these amounts of requests)
- With on-demand TLS active, all certificates are issued and maintained whenever there is the need to. Am I correct in the assumption that with on-demand TLS, the renewal process is never triggered by anything else than an incoming handshake? This is important to know, because I would like to avoid that something triggers the renewal of 100’000 domains simultaneously in the background.
I would really appreciate it if someone could help me with these questions. Thanks in advance!
this – I encourage all our large adopters to get a sponsorship to ensure that Caddy runs their critical operations smoothly, and to ensure ongoing maintenance of the project, etc. Sponsorships are customizable based on your needs, too. Let’s talk about that and help you get set up with your upgraded infrastructure!