Live data from Hacker News

The web server deployment model breaks at hobby scale

w.on-t.work

21–30 of 74 posts

Re: The web server deployment model breaks at hobby scale

#21
I literally just sent some friends a docker image and told them to point Luna at it, for which they were set up in ~20minutes and $3 of tokens, so I'm skeptical.

My homelab is also currently ~40 nix service VM's plus a handful of Ubuntu, etc long tail, and some external DO droplets for NAT, and a more robust vlan config than I'd ever been able to put time towards before... which I haven't had to do more than a dozen hours of manual setup on IN TOTAL thanks to Fable, Sol and local Qwen.

There's truth in this post, but I doubt it's longevity.

Re: The web server deployment model breaks at hobby scale

#23

I literally just sent some friends a docker image and told them to point Luna at it, for which they were set up in ~20minutes and $3 of tokens, so I'm skeptical. My homelab is also currently ~40 nix service VM's plus a handful of Ubuntu, etc long tail, and some external DO droplets for NAT, and a more robust vlan config than I'd ever been able to put time towards before... which I haven't had to do more than a dozen…

Why split the nix into so many VMs instead of just systemd units?

Re: The web server deployment model breaks at hobby scale

#26
post #5

I'm not sure I understand this post. Is this talking about self hosting Caddy in a home lab setting or just static web hosting on a VPS?

I think the author missed the root cause, which is the demise of (unencrypted) HTTP/1.1 connections.

I'm glad unencrypted http/1.1 was deprecated. I want a privacy online. TLS also gives you much better data integrity guarantees. Some ISPs - particularly in the US - actively inject javascript code into websites served over plain HTTP.

I just wish nginx / caddy / etc had better out-of-the-box support for letsencrypt. It would be way easier to set up if it was just built in to nginx. Let me specify my domain in my nginx config, and just make it work.

Re: The web server deployment model breaks at hobby scale

#27
post #17

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 cachi…

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

Re: The web server deployment model breaks at hobby scale

#28
At hobby scale, you don't have to care about the details. Just ship a zip or container image with docs and let the user figure out the rest. Self hosting is going to require some bit of expertise.

I personally don't like apps that ship the entire sink (complex stack) when I already have an opinionated setup that already includes TLS/access control/etc.

Re: The web server deployment model breaks at hobby scale

#29

This is only tangentially related, but I have a love-hate relationship with Immich. Love for everything, but loads of hate for the bug-o-feature that disallows sharing of albums if the website is not hosted over HTTPS. I can fiddle with the page content in Developer Tools to make it work, but frankly, WTF, especially since Immich expects people to set up a reverse proxy for HTTPS access on their own and does not help…

Honestly, this is a problem that has been solved by LLMs. Just point Claude Code to the server over SSH and say "We need Immich to be served over HTTPS". You could theoretically upstream the fixed compose.yaml if you felt like it, but the project seemed unusually hostile towards the one fix I tried to upstream.

Here's the entirety of the Caddy config to reverse proxy something with managed tls certs. I feel like it's not that big a deal?

  photos.example.com {
          reverse_proxy 127.0.0.1:8080 {
                  header_up X-Real-IP {remote_host}
          }
  }

Re: The web server deployment model breaks at hobby scale

#30
post #27
post #17

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 cachi…

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.

Post reply on HN