There’s a couple reasons. A practical one is that it makes it easiest to get a working setup when trying out the service. Otherwise you need to alter your DNS settings to connect to your site. Being able to run the Caddyfile in the docs to get a working site is (hopefully) a great first experience.
Sometimes you really want to test your HTTPS config, so HTTP doesn’t help. Like if you are setting up an HTTPS reverse proxy or using Caddy’s built-in automatic TLS feature. getlocalcert.net can allow you to use the same Caddyfile in production and testing (just use different config/credentials). Most web developers won’t care about that distinction, but anyone Ops side will. Sometimes your clients aren’t web browsers so the special treatment of localhost doesn’t apply.
There’s a couple reasons. A practical one is that it makes it easiest to get a working setup when trying out the service. Otherwise you need to alter your DNS settings to connect to your site. Being able to run the Caddyfile in the docs to get a working site is (hopefully) a great first experience.
Sometimes you really want to test your HTTPS config, so HTTP doesn’t help. Like if you are setting up an HTTPS reverse proxy or using Caddy’s built-in automatic TLS feature. getlocalcert.net can allow you to use the same Caddyfile in production and testing (just use different config/credentials). Most web developers won’t care about that distinction, but anyone Ops side will. Sometimes your clients aren’t web browsers so the special treatment of localhost doesn’t apply.