Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The web server deployment model breaks at hobby scale

w.on-t.work

Post reply on HN
Print view View original

11–20 of 74 posts

Re: The web server deployment model breaks at hobby scale

#11

Post by AussieWog93 »

sam_lowry_ wrote: post #4

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.

Re: The web server deployment model breaks at hobby scale

#12

Post by vehemenz »

scotty79 wrote: post #3

How many of these problems PHP solves out of the box or makes irrelevant?

It feels like there could be an entire longform piece on how "modern" web development norms arose because hobbyist/student web developers learned everything in an ad-hoc, local environment without access to, you know, a development server or a mature software stack.

Re: The web server deployment model breaks at hobby scale

#14

Post by jermaustin1 »

skydhash wrote: 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 will create one, and then run it, and update caddy server on its own.

Re: The web server deployment model breaks at hobby scale

#15

Post by KronisLV »

> 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!

Re: The web server deployment model breaks at hobby scale

#16

Post by deltarholamda »

bradly wrote: 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.

Re: The web server deployment model breaks at hobby scale

#17

Post by 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.

Re: The web server deployment model breaks at hobby scale

#18

Post by tingletech »

bradly wrote: 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 is distributing a web app that is run by hobbyists with a lot of esoteric home labs?
Post reply on HN