alt Hacker NewsThe web server deployment model breaks at hobby scale
Comments
I have 5Gbps fiber at home. LAN is mostly 10Gbps.
I'm hosting few hobbyist public websites. One is the library of hymns, songs, ... - mostly PDF, MP3, MIDI.
OpnSense router -> Traefik -> Docker container.
That Docker container runs on NAS, which is connected via 1Gbps port.
Suddenly, last week I started to get over 1000 RPS. Was it scanner, parser, crawler, DDOS? I can't tell, as user agent was default Mac OS.
It was using ~1Gpbs bandwidth. From many IPs. If I would have it hosted at AWS / Azure, it would cost me > $40 / hour for the bandwidth. Unless I use some of their CDN.
My router CPU went high, but it handled it ok. NAS CPU went high, but it handled it ok. Traefik loaded the server heavily: it had to both receive and send 1Gbps. And write access logs for all requests. My Alloy & Loki logging system got loaded heavily.
NAS already have cache. I tried to enable cache on Traefik. It went OOM in 2 minutes: https://github.com/darkweak/souin/issues/844
When I searched, I found that Traefik cache with proper memory handling is available only in Enterprise version.
Solved the issue by putting the site behind Cloudflare proxy and enabling it's magic to protect from the bot.
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.
> You document what needs to be reverse proxied and give examples for caddy and nginx, repeatedly cursing at nginx for not having an if that’s useful.
Somebody hasn't read the docs and doesn't understand how nginx's "if" works, because it's fantastically useful.
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.
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 host a webserver for a living, so I might be too far removed from the problem; I don't see anything that 1 minute of effort as part of a less-than-10-minute session with an agentic AI tool can't solve safely. A decent README and project structure is all Codex/CC/Pi needs. I mean this even for the least-technical person who would be self-hosting something.
I guess that breaks the plug-and-play nature, but you can't expect something internet-facing to be plug-and-play. (Maybe that's the real travesty here.)
> Deployments not using Docker will no longer be supported.
This is the way (while also allowing people to use their own proxies etc., but being clear about those not being officially supported).
Ship your back end container, your front end container, tell people how to set up the off the shelf DB containers or whatever else your software needs and if you don’t need 20 different components like Sentry self-hosted versions do, you’ll be fine. The DB can be a container or not. The reverse proxy can be a container or not. Hell, if someone wants to build the back end or front end from source and serve them differently they can, just on their own time. That’s pretty close to the 12 Factor App principles.
Just avoid a lot of complexity when possible: do traditional SSR, or with some progressive enhancements or what I like to do in this day and age (unless maximum accessibility is paramount) only use your back end for the API and have a traditional SPA, none of that complex Next.js stuff. Your front end just becomes a bundle of files that you can put in a web server container to be proxied by whatever the ingress is. At most the Docker entry point would change some values in config.json that the app loads on startup in the browser.
If someone asks for Kubernetes support or whatever, just wish them the best of luck in setting it up themselves!
> you have enough interactivity to warrant a single-page-application as your frontend. however, you also want people without javascript enabled to be able to read the bits that don’t require interaction.
I think at this point it's not a hobby, it's a burden.
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.
These all seem useful warnings to me, I'm vibing something for hobby scale. The installation script was the one place I needed to reorganize and make a lot of human-powered changes. And I haven't even distributed it yet :)
Damn, what a downer...
Hobby scale you said ? It doesn't have to be that complicated.
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 them in any way (like providing a pre-configured caddy in their compose.yaml, I don't know)
I get more blind visitors than visitors with javascript disabled these days
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 think I need. And I really want the app to only solve its essential problem. It should not take care of the IT part other than providing configuration samples.
How many of these problems PHP solves out of the box or makes irrelevant?
There's an easier solution. Just don't have private data. Then you don't need SSL either.
Unless you also want to deal with security, backups, GDPR compliance, etc.
Perhaps the article's title should be, "The web has become a hostile, largely automated environment and naive hobbyists may find it difficult to coexist with professional scrapers, scammers, grifters, bots, hucksters, and cybercriminals."
[dead]
This is quietly brilliant
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).