Save a ton of work by placing a http proxy infront of your NodeJS apps, and also let the http proxy serve static content. That way you dont have to implement a http-server+SSL+routing+file-server for each nodejs project. There are a lot of advantages to keeping a program small: For example less bugs, less maintenance, and faster implementation.

I second this. In production I will typically front my Node app with Nginx that takes care of SSL and static file serving. There is also a substantial performance benefit.

Can all be bundled up in a single Docker container for super easy deployment. :)

Me and my engineering team has been working with a combination of Zerotier + Caddy for a while now. We have a development domain and then every engineer has a subdomain, which is just `username.example.com` and `*.username.example.com` that points to their Zerotier address. Since it's all on a Zerotier network, we use DNS-01 validation, which works well.

Each engineer then has caddy running on his development machine with domains such as `server.username.example.com` and `web.username.example.com`.

The useful thing about this is that we're spread out remotely, but can at any point, while pairing or something like that, connect to the services running on each others machines. I've also grown used to simply using my own domain, rather than localhost, when developing, especially since it's served behind HTTPS.

If you own a domain, create a A record for local.mydomain.com and point it to 127.0.0.1 and you can generate a valid cert with Let's Encrypt.

In this case you'll need to use the DNS-01 validation method for the domain issuance, not HTTP-01 (because local.mydomain.com won't be able to receive an inbound validation connection from Let's Encrypt).

There's various tricks. You can also assign the domain to a static IP long enough to verify your ownership then change it. Using a TXT record is probably easier to automate renewal though.

thx for this method. Did not know that there is also another DNS based verification for normal subdomains on letsencrypt.

Alternatively, what I do is to sign a wildcard cert for a subdomain plus *.subdomain valid for a couple years and putting the key and cert on my Nextcloud in an encrypted archive file, that way I always have access to a cert that I trust and can easily install on a local computer.

You can also front it with Caddy in a single command, no need to generate the self-signed certificate manually and find a place to store it:

$ caddy -host localhost "proxy / localhost:9000" "tls self_signed"

This will serve your Node application (assuming it's on port 9000) at https://localhost:2015/. And you can change the port from the default port with the -port flag.

I've never tried to serve HTTPS locally without a proxy (ngrok etc.) or behind a load balancer, because I always end up serving the app with one or the other. And now there's Let's Encrypt. Why would you ever develop with HTTPS locally?

> Why would you ever develop with HTTPS locally?

One good reason is to mimic the production environment, as there are an increasing number of browser features that depend on HTTPS (HSTS, cookie secure flags, new html5 APIs like the location api, etc). Though when I do use https locally I also typically use an nginx reverse proxy.

While lots of browsers trust localhost, I've found that there is a significant problem with developing some features. My current project for example uses HttpOnly,Secure cookies, which don't work on localhost.

So either I add an option to disable that (which I don't want to) or I simply reroute my traffic over a domain pointed at localhost I have a cert for.

My particular use case might have been kind of weird, but -- I was working on a HTTPS client and I wanted to hit a local HTTPS server for some of the tests in the client.

HTTP/2 apps need TLS