Hacker News Reader

Comment by smashed | Hacker News Reader

I can relate to the TLS termination issue. It is difficult to provide a self hosted version of a web app with a sensible TLS setup.

The best is almost not to do it at all. Just have a docker image serve http/1.1 and document that a reverse proxy is required to expose the service.

There are simply too many ways to do it and every sys admin/hobbyist has their own preferred way.

For the anonymous and authenticated caching issues the author goes into, I think once again it is useless for self hosting. Just embed a performant web server like nginx for example that is pre configured to serve static files. Use proper headers, and predictable/simple paths. Self-hosted versions are going to be low traffic and just need to work.

Have advanced settings for more control, but keep the default simple and working out of the box with minimal dependencies.

View on HN

I don't know what you're on about. Just run Caddy and it does it all for you.

That is exactly what I am talking about.

You say caddy. The next person will say nginx-proxy-manager. The next will say DNS challenge let's encrypt behind wireguard VPN. The next will say Traefik. The next will say CloudFlare tunnels.

Everyone has their preferred solution and its always the best and simplest.

As the next person on this post, I second Caddy

Ok I'll bite again.

Do you want a caddy service embedded with every web app you self host or are you running a single one serving all your apps?

From my understanding if you want acme http challenges to just work with let's encrypt you probably need to use a single, separated caddy to front all your apps.

In that case if I ship a caddy service pre configured to do TLS termination with my app it's just more trouble for you no?

Fair enough, http is enough - I anyways have one caddy to rule them all. However, if your app is picky about reverse proxying, e.g. headers, please add a sample caddy config. It's often the first thing I'm looking for if I'm trying out a tool and want to host it under a subdirectory before configuring a subdomain.

No, HTTP is not enough, I submitted a couple HTTP-only links to HN lately, they got flagged within half an hour, even HN crowd can not open HTTP links anymore ;-)

That's not really HN's fault but all modern browsers will warn the user before accessing an http site with a security warning.

My point was not to use http only as a finished solution, but to let the admin front the http-only service with their TLS termination solution of choice.

We are talking about hobbyists here.

... Of which (TLS terminators) caddy is IMO the easiest for hobbyists, as was the starting point of this subthread

I already commented on this twice here, but here it goes again:

I self-host Immich with Caddy as TLS terminator, and it's far from obvious.

They all run on a small N150 PC in my closet, the same PC serves as my internet router. Both Immich and Caddy run in podman-compose, and there are firewall rules that allow incoming traffic to Caddy and outgoing traffic from Caddy to update certificates. There's also a tricky setup of Systemd dependencies that make sure podman networking and firewall rules play nicely together and with other system config, like the bridge for the 2.4Gz range internal Wi-Fi and for external 5Gz Wi-Fi 6 card.

If not for the LLM help, I would have spent many days figuring out all the rough edges of this setup.

Which is exactly the point OP is making. Hobbying webhosting is hard nowadays.

Just provide a docker compose file.

I posted this in a sibling thread, but it's also appropriate here.

I self-host Immich with Caddy, and it's complex, really.

Caddy runs in podman compose next to Immich, there are firewall rules to allow traffic in and out and proper dependencies in custom systemd units in case podman networking goes bust after firewall rules are reloaded and a readme that covers all that.

Exactly the point OP is making.

As a one-person-scale selfhoster that has wrangled Apache and nginx before, I'm also saying go for caddy straight away.

What it shows is that there are a big number ofeasy options if you want to.

Just commenting to represent the NPM referrers that you mentioned, since it seems most HN users are Caddy enjoyers

Nah he's entirely right. Serve http, let the user do https.

If you want to put caddy in front of yours? Great it works.

For me, running a much larger setup? Great, it also works.

For users who never expose it beyond an IP address on lan? Great it also works.

That is why my webserver only server-negotiate Cha-Cha/Poly at TLS level and rejects all else.

No caddy. No cache. No proxy.

A lot of scrapers give up.

Log rate remains low. Actual visits even lower.

Peace of mind, for a while:

https://egbert.net/blog/articles/index.html

Reply on news.ycombinator.com