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 :)
The web server deployment model breaks at hobby scale
31–40 of 74 posts
Re: The web server deployment model breaks at hobby scale
#32Earlier 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.
As the next person on this post, I second Caddy
Re: The web server deployment model breaks at hobby scale
#33Damn, what a downer...
Hobby scale you said ? It doesn't have to be that complicated.
Re: The web server deployment model breaks at hobby scale
#34> 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.
Re: The web server deployment model breaks at hobby scale
#35I get more blind visitors than visitors with javascript disabled these days
Re: The web server deployment model breaks at hobby scale
#36I 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.
Re: The web server deployment model breaks at hobby scale
#37Earlier quoted context omitted.
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?
Re: The web server deployment model breaks at hobby scale
#38Earlier 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.
As a one-person-scale selfhoster that has wrangled Apache and nginx before, I'm also saying go for caddy straight away.
Re: The web server deployment model breaks at hobby scale
#39Earlier 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…
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.
Re: The web server deployment model breaks at hobby scale
#40Earlier quoted context omitted.
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} } }
caddy passes on the source IP by default so it's even easier than that
photos.example.com {
reverse_proxy 127.0.0.1:8080
}