How to handle thousands of certificates in one single server


We have a SAAS web builder platform where customers can create and publish their own website (like Squarespace). Currently there are 2k+ websites running in one single server and multiple databases.

What is the best solution to handle all their SSL certificates using Let’s Encrypt and NGINX?
At the moment we do it manually but server blocks are growing. We need a solution for scale.


1 Like

hi @diegoiglesias

if you issue subdomains e.g then a wildcard makes sense

if this is not the case then have a look at some of the suggestions here:


1 Like

Are you currently generating/managing the nginx server blocks automatically? Do you need wildcards or non-wildcard certificates?

If you wanted to minimize the amount of work you need to do:

  1. Have your generated nginx blocks include a location /.well-known/acme-challenge { root /var/www/letsencrypt; } block for each domain to serve the validation files from a central location.
  2. Initially (such as when a customer domain is created), use an existing ACME client (I can recommend acmetool) to try issue a certificate for the domain (e.g. acmetool want customer-domain.example). Periodically check if the certificate issuance succeeds.
  3. Once the ACME client succeeds to fetch a certificate for the domain, detect this and update the customer’s nginx server block to include the certificates.
  4. Let the ACME client crons deal with renewal and reloading nginx.

Otherwise I imagine you will need to manually integrate ACME into the workflow of your SaaS application (which really is the proper approach anyway).

I know that reverse proxies like Caddy (and possibly others) have a superior story when it comes to integrating ACME - you don’t need to do much manually, it will fully manage the issuance/renewal/deployment lifecycle for you.

For nginx there is a Let’s Encrypt/ACME module that exists, but it seems like it may be dead.


Just want to second what was said, that Caddy is indeed capable of this. Caddy’s ACME integration is entirely native and first-class, serving all sites over HTTPS by default and taking care of things for you, including HTTP->HTTPS redirects. Caddy’s underlying ACME library was also one of the first third-party libraries available, with arguably one of the most robust cores. Caddy (and its underlying lib, xenolf/lego) is, AFAIK, the only major client that was basically unaffected by Let’s Encrypt outages in the past and this current change with TLS-SNI being disabled.

I know of Caddy instances that serve thousands of sites on a single machine and manage the certificates for them. I think you’ll find it a low-friction solution. (We also have commercial licenses and support options for businesses like yours, which I highly recommend. Feel free to contact me privately for more info.)


Hi mholt, thank you for your response. I’ve been checking Caddy out, and it looks very promising. Though I have to admit that I’m quite skeptical to make the move and replace nginx (which is already serving thousands of websites) with a v0.1010 server. Can you tell me more about it so that I make myself a better idea?

1 Like

Sure. I can understand that; I recommend starting with a small batch of sites so you can get comfortable with it first. Most people who are looking on making the switch (as opposed to starting a new project or product with Caddy from the beginning) do this, and ease themselves into it. Most find that it works pretty well, even if it means thinking about your web server a little differently.

In any case, I guarantee that an integrated ACME client such as what Caddy has will provide a smoother, lower-maintenance experience than disparate processes as (and with) external dependencies.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.