HN Explorer

4 comments

[ 6.3 ms ] story [ 13.3 ms ] thread
justsomehnguy
TL;DR I hate running a web-proxy/balancer so I run a different case of proxy.

IMO the described process can be useful sometimes, but adds some complexity in the app deployment, like the need to configure certificates in the app itself[0], not at the proxy, which can be (a bit more) troublesome if you are okay with a single WC certificate serving all your subdomains.

And the OP still uses Apache for 80->443 redirect.

[0] as I understood the article, though this can be preffered if the proxy (snid in this case) shouldn't have the access to the plain-text data

agwa
> like the need to configure certificates in the app itself[0], not at the proxy, which can be (a bit more) troublesome if you are okay with a single WC certificate serving all your subdomains.

At this point, certificate management is 100% automated, so it makes no difference where the certs are configured.

> And the OP still uses Apache for 80->443 redirect.

As I mentioned in the post, I plan to use a tiny zero-config daemon for this purpose. Getting rid of Apache is an incremental process and I'm not 100% there yet.

justsomehnguy
> Getting rid of Apache is an incremental process and I'm not 100% there yet.

You can replace it with Nginx with a simple config like this, I suppose:

    server {
        listen 80 default_server;
        server_name _;
        return 301 https://$host$request_uri;
    }
jbverschoor
I dunno. Just bind your app to a named socket, and use that in nginx or caddy