Live data from Hacker News

Self-Host and Tech Independence: The Joy of Building Your Own

ssp.sh

131–140 of 247 posts

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#131

Earlier quoted context omitted.

Or they have explored other options and find docker lacking. I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (which can optionally easily be wrapped into containers if you want on nixos, but there you're using containers for their isolation features, not for the ability to 'docker pull', and for many purposes you can probably e.g. ju…

> Or they have explored other options and find docker lacking. I don't think so. Containerization solves about 4 major problems in infrastructure deployment as part of it's happy path. There is a very good reason why the whole industry pivoted towards containers. > . I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (...) This comment…

I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers. Containers per se are just various Linux namespace features, and are unrelated to e.g. distribution or immutable images. So it makes sense to mention experience with the systems that are built around containers.

The point is when you have experience with a Linux distribution that already does immutable, declarative builds and easy distribution, containers (which are also a ~2 line change to layer into a service) are a rather specific choice to use.

If you've used these things for anything nontrivial, yes systemd units are way simpler than docker run. Debugging NAT and iptables when you have multiple interfaces and your container doesn't have tcpdump is all a pain, for example. Dealing with issues like your bind mount not picking up a change to a file because it got swapped out with a `mv` is a pain. Systemd units aren't complicated.

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#132

Earlier quoted context omitted.

Yes but arguably anything below the equivalent of RAID6/RAIDZ2 puts you at a not inconsiderable risk of data loss. Most laptops cannot do parity of any sort because of a lack of SATA/M.2 ports so you will need new hardware if you want the resilience offered by RAID. Ideally you will want that twice on different machines if you go by the "backups in at least 2 different physical locations" rule.

To be honest I never understood the purpose of RAID for personal use cases. RAID is not a backup, so you need frequent, incremental backups anyway. It only makes sense for things where you need that 99.99% uptime. OK, maybe if you're hosting a service that many people depend on then I could see it (although I suspect downtime would still be dominated by other causes) but then I go over to r/DataHoarder and I see peop…

i use mirror raid on my desktop. the risk of a disk dying is just to high. i even made sure to buy disks from two different vendors to reduce the chance of them dying at the same time. for the laptop i run syncthing to keep the data in sync with the desktop and a remote server. if the laptop dies i'll only be a few minutes out. when travelling i sync to a USB drive frequently.

for the same reason i don't buy laptops with soldered SSD. if the laptop dies, chances are the SSD is still ok, and i can recover it easily.

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#133

Earlier quoted context omitted.

> Or they have explored other options and find docker lacking. I don't think so. Containerization solves about 4 major problems in infrastructure deployment as part of it's happy path. There is a very good reason why the whole industry pivoted towards containers. > . I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (...) This comment…

I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers. Containers per se are just various Linux namespace features, and are unrelated to e.g. distribution or immutable images. So it makes sense to mention experience with the systems that are built around containers. The point is when you have experience with a Linux distribution t…

> I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers.

No, it sounds like a poorly thought through strawman. Even Docker supports Docker swarm mode and many k8s distributions use containerd instead of Docker, so it's at best an ignorant stretch to jump to conclusions over k8s.

> Containers per se are just various Linux namespace features, and are unrelated to e.g. distribution or immutable images. So it makes sense to mention experience with the systems that are built around containers.

No. Containers solve many operational problems, such as ease of deployment, setup software defined networks, ephemeral environments, resource management, etc.

You need to be completely in the dark to frame containerization as Linux namespace features. It's at best a naive strawman, built upon ignorance.

> If you've used these things for anything nontrivial, yes systemd units are way simpler than docker run.

I'll make it very simple to you. I want to run postgres/nginx/keycloak. With Docker, I get everything up and running with a "docker run ".

Now go ahead and show how your convoluted way is "way simpler".

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#134

Earlier quoted context omitted.

I would agree with that. Docker has a lot of use cases but self hosting is not one of them. When self-hosting you wanna think long term and the fact you will loose interest in the fiddling after a while. So sticking with software packaged in a good distribution is probably the way to go. This is the forgotten added value of a Linux or BSD distribution, a coherent system with maintenance and an easy upgrade path. The…

I feel the exact opposite. Docker has made self-hosting so much easier and painless. Backing up relevant configuration and data is a breeze with Docker. Upgrading is typically a breeze as well. No need to suffer with a 5-year old out of date version from your distro, run the version you want to and upgrade when you want to. And if shit hits the fan, it's trivial to roll back. Sure, OS tools should be updated by the d…

> Docker has made self-hosting so much easier and painless.

Mostly agreed, I actually run most of my software on Docker nowadays, both at work and privately, in my homelab.

In my experience, the main advantages are:

  - limited impact on host systems: uninstalling things doesn't leave behind trash, limited stability risks to host OS when running containers, plus you can run a separate MariaDB/MySQL/PostgreSQL/etc. instance for each of your software package, which can be updated or changed independently when you want
  - obvious configuration around persistent storage: I can specify which folders I care about backing up and where the data that the program operates on is stored, vs all of the runtime stuff it actually needs to work (which is also separate for each instance of the program, instead of shared dependencies where some versions might break other packages)
  - internal DNS which makes networking simpler: I can refer to containers by name and route traffic to them, running my own web server in front of everything as an ingress (IMO simpler than the Kubernetes ingress)... or just expose a port directly if I want to do that instead, or maybe expose it on a particular IP address such as only 127.0.0.1, which in combination with port forwarding can be really nice to have
  - clear resource limits: I can prevent a single software package from acting up and bringing the whole server to a standstill, for example, by allowing it to only spike up to 3/4 CPU cores under load, so some heavyweight Java or Ruby software starting up doesn't mean everything else on the server freezing for the duration of that, same for RAM which JVM based software also loves to waste and where -Xmx isn't even a hard limit and lies to you somewhat
  - clear configuration (mostly): environment variables work exceedingly well, especially when everything can be contained within a YAML file, or maybe some .env files or secrets mechanism if you're feeling fancy, but it's really nice to see that 12 Factor principles are living on, instead of me always needing to mess around with separate bind mounted configuration files
There's also things like restart policies, with the likes of Docker Swarm you also get scheduling rules (and just clustering in general), there's nice UI solutions like Portainer, healthchecks, custom user/group settings, custom entrypoints and the whole idea of a Dockerfile saying exactly how to build an app and on the top of what it needs to run is wonderful.

At the same time, things do sometimes break in very annoying ways, mostly due to how software out there is packaged:

https://blog.kronis.dev/blog/it-works-on-my-docker

https://blog.kronis.dev/blog/gitea-isnt-immune-to-issues-eit...

https://blog.kronis.dev/blog/docker-error-messages-are-prett...

https://blog.kronis.dev/blog/debian-updates-are-broken

https://blog.kronis.dev/blog/containers-are-broken

https://blog.kronis.dev/blog/software-updates-as-clean-wipes

https://blog.kronis.dev/blog/nginx-configuration-is-broken

(in practice, the amount of posts/rants wouldn't change much if I didn't use containers, because I've had similar amounts of issues with things that run in VMs or on bare metal; I think that most software out there is tricky to get working well, not to say that it straight up sucks)

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#136
post #63
post #49

Earlier quoted context omitted.

https://kiwix.org/en/ and some jellyfin setups are a great offline resource. But yeah, things like NixOS and Gentoo get very unhappy when they don't have Internet for more things. And mirroring all the packages ain't usually an option.

I'm not too familiar with NixOS, but I've been running Gentoo for ages and don't know why you'd need constant internet. Would you mind elaborating?

For installing new things - they assume a working Internet.

Ubuntu and CentOS at least HAD the concept of a "DVD" source, though I doubt it is used much anymore.

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#137

Earlier quoted context omitted.

I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers. Containers per se are just various Linux namespace features, and are unrelated to e.g. distribution or immutable images. So it makes sense to mention experience with the systems that are built around containers. The point is when you have experience with a Linux distribution t…

> I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers. No, it sounds like a poorly thought through strawman. Even Docker supports Docker swarm mode and many k8s distributions use containerd instead of Docker, so it's at best an ignorant stretch to jump to conclusions over k8s. > Containers per se are just various Linux namespace…

Containers do not do deployment (or set up software defined networks). docker or kubernetes (or others) do deployment. That's my point.

nix makes it trivial to set up ephemeral environments: make a shell.nix file and run `nix-shell` (or if you just need a thing or two, do e.g. `nix-shell -p ffmpeg` and now you're in a shell with ffmpeg. When you close that shell it's gone). You might use something like `direnv` to automate that.

Nixos makes it easy to define your networking setup through config.

For your last question:

    services.postgres.enable = true;
    services.nginx.enable = true;
    services.keycloak.enable = true;
If you want, you can wrap some or all of those lines in a container, e.g.

    containers.backend = {
        config = { config, pkgs, lib, ... }: {
            services.postgres.enable = true;
            services.keycloak.enable = true;
        };
    };
Though you'd presumably want some additional networking and bind mount config (e.g. putting it into its own network namespace with a bridge, or maybe binding domain sockets that nginx will use plus your data partitions).

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#138
post #107

Earlier quoted context omitted.

Absolutely everything they said makes sense. Everything you're saying is complete overkill, even in most Enterprise environments. We're talking about a home server here for hosting eBooks and paperless documents, and you're implying Kubernetes clusters are easy enough to run and so are a good solution here. Madness. > I have news for you. I have news for _you_: using Docker to run anything that doesn't need it (i.e.…

> Absolutely everything they said makes sense. Not really. It defies any cursory understanding of the problem domain, and you must go way out of your way to ignore how containerization makes everyone's job easier and even trivial to accomplish. Some people in this discussion even go to the extreme of claiming that messing with systemd to run a service is simpler than typing "docker run". It defies all logic. > Everyt…

> you must go way out of your way to ignore how containerization makes everyone's job easier and even trivial to accomplish

You'd have to go out of your way to ignore how difficult they are to maintain and secure. Anyone with a few hours of experience trying to design an upgrade path for other people's container; security scanning of them; reviewing what's going on inside them; trying to run them with minimal privileges (internally and externally), and more, will know they're a nightmare from a security perspective. You need to do a lot of work on top of just running the containers to secure them [1][2][3][4] -- they are not fire and forget, as you're implying.

This one is my favourite: https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Se... -- what an essay. Keep in mind someone has to do that _and_ secure the underlying hosts themselves for there is an operating system there too.

And then this bad boy: https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR... -- again, you have to do this kind of stuff _again_ for the OS underneath it all _and_ anything else you're running.

[1] https://medium.com/@ayoubseddiki132/why-running-docker-conta...

[2] https://wonderfall.dev/docker-hardening/

[3] https://www.isoah.com/5-shocking-docker-security-risks-devel...

[4] https://kubernetes.io/docs/tasks/administer-cluster/securing...

They have their place in development and automated pipelines, but when the option of running on "bare metal" is there you should take it (I actually heard someone call it that once: it's "bare metal" if it's not in a container these days...)

You should never confuse "trivial" with "good". ORMs are "trivial", but often a raw SQL statement (done correctly) is best. Docker is "good", but it's not a silver bullet that just solves everything. It comes with its own problems, as seen above, and they heavily outweigh the benefits.

> Explain in detail how being able to run services by running "docker run" is "overkill". Have you ever went through an intro to Docker tutorial?

Ah! I see now. I don't think you work in operations. I think you're a software engineer who doesn't have to do the Ops or SRE work at your company. I believe this to be true because you're hyper-focused on the running of the containers but not the management of them. The latter is way harder than managing services on "bare metal". Running services via "systemctl" commands, Ansible Playbooks, Terraform Provisioners, and so many other options, has resulted in some of the most stable, cheap to run, capable, scalable infrastructure setups I've ever seen across three countries, two continents, and 20 years of experience. They're so easy to use and manage, the companies I've helped have been able to hire people from University to manage them. When it comes to K8s, the opposite is completely true: the hires are highly experienced, hard to find, and very expensive.

It blows my mind how people run so much abstraction to put x86 code into RAM and place it on a CPU stack. It blows my mind how few people see how a load balancer and two EC2 Instances can absolutely support a billion dollar app without an issue.

> You're just publicly stating your ignorance. Do yourself a favor and check Ubuntu's microk8s. You're mindlessly parroting cliches from a decade ago.

Sure, OK. I find you hostile, so I'll let you sit there boiling your own blood.

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#139
post #73

Warning: shameless plug ahead Self-hosting doesn’t mean you have to buy hardware. After a few years, low-end machines are borderline unusable with Windows, but they are still plenty strong for a Linux server. It’s quite likely you or a friend has an old laptop laying around, which can be repurposed. I’ve done this with an i3 from 2011 [1] for two users, and in 2025 I have no signs that I need an upgrade. Laptops are…

Speaking of laptop batteries as a UPS source, some laptops come with battery management features that keep the battery healthy even when plugged in full time, usually exposed as a setting in the BIOS/UEFI. I've found that business/enterprise type laptops like Thinkpads and Probooks have this as standard, for example Thinkpads from 2010 already had this, assuming you're lucky enough to find one with a usable battery o…

Macbooks do this as well automatically if kept plugged in for a certain period of time.

Re: Self-Host and Tech Independence: The Joy of Building Your Own

#140
I highly recommend anyone going this route to use Proxmox as your base install on the (old) hardware, and then use individual LXCs/VMs for the services you run. Maybe it's just me, but I find LXCs to be much easier to manage and reason about than Docker containers, and the excellent collection of scripts maintained by the community: https://community-scripts.github.io/ProxmoxVE/scripts makes it just as easy as a Docker container registry link.

I try to use LXCs whenever the software runs directly on Debian (Proxmox's underlying OS), but it's nice to be able to use a VM for stuff that wants more control like Home Assistant's HAOS. Proxmox makes it fairly straightforward to share things like disks between LXCs, and automated backups are built in.

Post reply on HN