Live data from Hacker News

The web server deployment model breaks at hobby scale

w.on-t.work

41–50 of 75 posts

Re: The web server deployment model breaks at hobby scale

#41
post #37

Earlier quoted context omitted.

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

Just provide a docker compose file.

Re: The web server deployment model breaks at hobby scale

#42
post #22

Was this written by the Department of Demoralization?

Such defeatism indeed. I understand that things look complex but plenty of very complex apps can be self-hosted and they Just Work [TM]. Now, sure, there's work involved. But, just like many others, I can run Plex, JellyFin or Immich just fine and those are more complex than 99% of all webapps ever shipped.

We'got all the world's knowledge compressed and queryable with LLMs: there are way less configuration issues that I cannot solve today than used to be the case.

Did those in charge of those standards royally fuck up HTTPS/TLS? Of freakin' course they did. The interests of the big players, not the small ones, have been taken care of. And the result is an ultra complex mess of fucktarded standards.

But it is what is: it's what we have. And we'll make it work.

Re: The web server deployment model breaks at hobby scale

#43
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?

It's partially about how complicated modern Web services can be, and why so many people just give up and ship a Docker container. It's also about how agonizing over the details is sometimes just wasted because all of your users are just AI scrapers. An art professor I knew used to say about overwrought paintings "too much sugar for a dime". Technical people are often prone to this as well.

Thank you. This makes more sense. I have an open source web app and it uses Docker (Kamal specifically) to make it easy for others to deploy.

Re: The web server deployment model breaks at hobby scale

#44
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.

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.

Re: The web server deployment model breaks at hobby scale

#45
post #9

All of those requirements seem weird. I selfhost a few software and the user count is one. My extent at sysadmin is to write a systemd service, configure the proxy (if it’s on a vps and I use subdomains), and maybe use ansible for scripting the provisioning and deploy. It’s fine to publish recommendations how to tune configurations for specific usages. But I only need the app, not the various things that you may thin…

And I do `docker compose up` now with a caddy server in front of docker, so I can just add a new site (sub domain or directory) that reverse proxies to that docker container's port. And the beauty is, that I have a skill for it for claude code, so I actually don't have to do any of that for my local self-hosted stuff. I just call /publish-local-docker subdomain.mydomain.local And if there isn't a docker compose, it w…

[dead]

Re: The web server deployment model breaks at hobby scale

#46
Most of these problems are actually solved with containers, though.

An opinionated release of k8s (k3s, microk8s, etc) does wonders for making much of it just disappear.

You pay a slightly higher up front cost in complexity, in return for largely removing absolutely all the listed problems in this blog.

If you're going to run more than just one app... It's the route I'd recommend.

I think the market is already moving here, too. Synology is exposing very easy interfaces to run container workloads on their devices.

I think we're headed towards something like a combo NAS/router that handles storage and networking (by far the hardest parts of hosting).

Re: The web server deployment model breaks at hobby scale

#47

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?

They're not all tooootally atomic, I have clustered things like libation+audiobookshelf, ollama+ds4+litellm, but I like that I can manage things almost entirely at the network and host level, generally atomically per service, and especially between services (eg homeassistant and the local ai).

It's DEFINITIVELY overkill, and fills up fast, but nix making everything near fully declarative to roll fwd/back or shuffle between proxmox hosts at any time makes for a clean and easy mental model. Both for me and the AI, because it can infinitely retry a nix flake config until it gets it perfect.

Re: The web server deployment model breaks at hobby scale

#48
post #30
post #27

Earlier quoted context omitted.

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.

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

Re: The web server deployment model breaks at hobby scale

#49

Earlier quoted context omitted.

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

They're not all tooootally atomic, I have clustered things like libation+audiobookshelf, ollama+ds4+litellm, but I like that I can manage things almost entirely at the network and host level, generally atomically per service, and especially between services (eg homeassistant and the local ai). It's DEFINITIVELY overkill, and fills up fast, but nix making everything near fully declarative to roll fwd/back or shuffle b…

Sounds like a poster child for LXC containerization with Proxmox — all the host-level management of a non-ephemeral VM (including snapshots!), without the every-machine-has-its-own-kernel overhead.

Re: The web server deployment model breaks at hobby scale

#50
Lots of things break at hobby scale, mainly because hobbyists can have a huge range of experience, expertise, and willingness to do things themselves.

Anyone serving hobbyists, commercially or on a volunteer basis, needs to accept that there will be some number of hobbyists “below the line” of what you can reasonably support. Those folks will just struggle with what you can provide to them, and you will never be able to address all their complaints, concerns, mistakes, etc.

You just have to mentally cast them free on their own. At most, encourage them to find fellow hobbyists who can help them level up where they need to in order to engage with your offering.

Post reply on HN