Why Web Server Deployment Fails for Hobby Projects
The web server deployment model breaks at hobby scale
The conventional model of deploying web servers—provisioning a VM, configuring nginx, managing SSL, and monitoring uptime—breaks down when you're just running a small personal project. The overhead of infrastructure management dwarfs the actual code, making the hobby scale unsustainable. This piece argues for simpler, more direct deployment approaches that fit the reality of small-scale, low-traffic applications.
- SlavikCA
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.
- smashed
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.
- lee_ars
> 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.
- turtlebits
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.
- bradly
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?