You configure Caddy to disable certain challenge types[0], which in this is the HTTP challenge, like so:

    example.com {
     tls {
      issuer acme {
       disable_http_challenge
      }
     }
     file_server
    }

[0] https://caddyserver.com/docs/caddyfile/directives/tls#acme

> Can't do http challenges because my ISP blocks port 80 inbound.

My ISP also put me behind CGNAT, which effectively meant that all of the inbound traffic got dropped. I worked around that by getting the cheapest VPSes that I could find and then setting up WireGuard and simply forwarding the traffic to my homelab servers. So I got all of the compute that I have available locally, all of the RAM and all of the cheap HDD storage, but a static IP address.

I actually wrote about the process a few years ago: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...

(note that you probably would only want to forward 80 and 443 ports in most cases, not everything; outside of testing boxes)

Personally, I opted for Time4VPS in the end, which I use for the rest of my hosting as well: https://www.time4vps.com/linux-vps/?affid=5294#annually (affiliate link, they do have good discounts at the moment for yearly billing, though)

Then again, something like Scaleway Stardust instances could also be a really good fit, when they are available: https://www.scaleway.com/en/stardust-instances/

For those not chasing after the savings of a few Euros, Hetzner is also going to be more than enough: https://www.hetzner.com/cloud (or DigitalOcean, or Vultr, or any other VPS provider out there)

I don't need port 80 now that DNS challenges are easily automated. Port 443 is open, so that's fine.

Also, if I have a VPS, why not just serve from the VPS?