Hacker News new | ask | show | jobs
by cyfex 1616 days ago
I always found the hurdle with self-hosting to be maintaining, not the initial setup. Things like upgrading, in order to keep getting security fixes, and verifying everything works after the upgrade, are what has taken the most effort and time in the past for me.

This looks like a great setup by the author, but difficult to maintain in the long run without significant time investment.

3 comments

Docker and docker-compose make maintaining stuff dead simple to me. In like 95% of the cases it's just a matter of changing the version in a YAML file and running one command, and in the remaining 5% of the time I'm not concerned at all with some downtime because I'm (mostly) the only user.
This. I used to host directly on my server and discovered docker a few years ago.

It was a relief. Coupled with watchtower the updates are automatic except for the two services I really rely upon.

I used to be on Ubuntu for ages and moved to Arch a few days ago - my server only runs docker today.

I still want to keep access to a shell do it is Arch and not Rancher or something (I did not research much the bare metal hypervisors).

My maintenance is minutes every month if everything works fine, up to a max of an hour when Home Assistant broke things once two years ago.

DRP from bare metal is an hour.

Adding a service is a few minutes.

Containers are not good for security updates.

docker also adds a big attack surface.

What do you use for serving docker-compose?
Docker-compose doesn't need "served" per-se - it lets you run some containers, and handles some lightweight orchestration around them, so that you have groups of containers for a service (i.e. a Wordpress service compromises a mariadb container and a Wordpress container). The compose file handles port bindings/mappings.

If you then want to put a reverse proxy in front of the docker containers (you almost invariably will), then you can look at different options like caddy, Traefik, nginx etc. I, for one, like to be old-fashioned and have my docker containers' ports bound to localhost, then manually maintain my own "outside of docker" instance of nginx as a reverse proxy that uses these as upstreams. That's not the most "container-first" way of working, but it worked for me. Caddy can do similar. Traefik is more integrated with docker and the docker ecosystem, but that might do what you need better.

True, it's not easy. In the past I used to run everything on Debian stable for that reason. And after every two years or so, I'd book two days for the upgrade, with some time offline.

The problem was, at some point Debian stable got so distant from modern infrastructure you had to patch it from the beginning with newer versions, so reluctantly I switched to testing (that was years ago). I was surprised to find out things were working just fine.

The problem is today everybody distributes software in their own way. Especially web software - native packages are more and more rare. So automatic updates that work are indeed a challenge.

Automating it away (Ansible and Docker) is a good way to reduce overhead. I barley invest any time in maintaining my infrastructure.