- you do not need kubernetes
- you do not need anything to be „high availability”, that just adds a ton of complexity for no benefit. Nobody will die or go broke if your homelab is down for a few days.
- tailscale is awesome
- docker-compose is awesome
- irreplaceable data gets one offsite backup, one local backup, and ideally one normally offline backup (in case you get ransomwared)
- yubikeys are cool and surprisingly easy to use
- don’t offer your services to other people until you are sure you can support it, your backups are squared away, and you are happy with how things are set up.
this post was submitted on 30 Jul 2024
0 points (50.0% liked)
Selfhosted
39245 readers
258 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
To piggy back on your “You don’t need k8s or high availability”,
If you want to optimize your setup in a way that’s actually beneficial on the small, self hosted scale, then what you should aim for is reproducibility. Docker compose, Ansible, NixOS, whatever your pleasure. The ability to quickly take your entire environment from one box and move it to another, either because you’re switching cloud providers or got a nicer hardware box from a garage sale.
When Linode was acquired by Akamai and subsequently renamed, I moved all my cloud containers to Vultr by rsyncing the folder structure to the new VM over SSH, then running the compose file on the new server. The entire migration short of changing DNS records took like 5 minutes of hands-on time.
Ansible is so simple yet so elegant.
I wish I knew not to trust closed source self-hosted applications, such as Plex. Would have saved a lot of time and money.
Can you elaborate?
Plex is a great example here. I've been Hetzner customer for many many years, and bought a lifetime license to Plex. Only to receive few months later a notification from Plex that I am no longer allowed to self-host Plex for myself(and only myself) at Hetzner and that they will block all access to my self-hosted Plex instance. I tried to ask for leniency or a refund, but that was wasted effort as well.
In short, I was caught on a crossfire when for-profit company tried to please hollywood by attempting to reduce piracy, so they could get new VC funding.
...
I am now a happy Jellyfin user and warmly recommend all Plex users to try it, the Jellyfin community is awesome!
(Use your favourite search engine to look up "Hetzner Plex ban" for more details)
Podman quadlets have been a blessing. They basically let you manage containers as if they were simple services. You just plop a container unit file in /etc/containers/systemd/, daemon-reload and presto, you've got a service that other containers or services can depend on.
Benefits:
-
Cheap storage that I can use both locally and as a private cloud. Very convenient for ~~piracy~~ storing all my legally obtained files.
-
Network wide adblocking. Massive for mobile games/apps.
-
Pivate VPN. Really useful for using public networks and bypassing network restrictions.
-
Gives me an excuse to buy really cool, old server and networking hardware.
As for things I wish I knew... Don't use windows for servers. Just don't.
SMB sucks, try NFS.
Use docker, managing 5 or 10 different apps without containers is a nightmare.
Bold of you to assume I'm a computer scientist or engineer or that I have a degree lmao. I just hate ads, subscriptions and network restrictions, so I learned how to avoid those things. As for resources to get started... Look up TrueNAS scale. It basically does all of the work for you.
I'll parrot the top reply from Reddit on that one: to me, self hosting starts as a learning journey. There's no right or wrong way, if anything I intentionally do whacky weird things to test the limits of my knowledge. The mistakes and troubles are when you learn. You don't really understand the significance of good backups until you had to restore from them.
Even in production, it differs wildly. I have customers whom I set up a bare metal Ubuntu in some datacenter for cheap, they've been running on that setup for 10 years. Small mom and pop shop, they will never need a whole cluster of machines. Then at my day job we're looking at things like Kubernetes and very heavyweight stacks because we handle a lot of traffic.
Some people self-host a PiHole on a Raspberry Pi and that's all they need. Some people have entire NAS setups with smart TVs accessing their Plex/Jellyfin servers for the whole extended family. I host my own emails, which is a pain in the ass to get working reliably and clean your IP reputation.
I guess the only thing you should know is, you need some time to commit to maintaining your stuff if you don't want it to break or get breached (if exposed to the Internet), and a willingness to learn because self hosting isn't a turnkey experience. It can be a turnkey installation but when your SD card/drives fails you're still on your own to troubleshoot and fix it. You don't set a NextCloud server to replace Google Drive with the expectation that you shove the server in a closet forever. Owning your infrastructure and data comes at a small but very important upkeep time investment.
The big thing for #2 would be to seperate out what you actually need vs what people keep recommending.
General guidance is useful, but there's a lot of 'You need ZFS!' and 'You should use K8s!' and 'Use X software!'
My life got immensely easier when I figured out I did not need any features ZFS brought to the table, and I did not need any of the features K8s brought to the table, and that less is absolutely more. I ended up doing MergerFS with a proper offsite backup method because, well, it's shockingly low-complexity.
And I ended up doing Docker with a bunch of compose files and bind mounts, because it's shockingly low-complexity. And it's just running on Debian, instead of some OS that has a couple of layers of additional software to make things "easier" because, again, it's low-complexity.
I can re-deploy the entire stack on new hardware in about ~10 minutes (I've tested this a few times just to make sure my backup scripts work), and there's basically zero vendor tie-in or dependencies that you'd have to get working first since it's just a pile of tarballs and packages from the distro's package manager on, well, ANY distro.
My life got immensely easier when I figured out I did not need any features ZFS brought to the table, and I did not need any of the features K8s brought to the table, and that less is absolutely more.
Same here. Sometimes I get carried away, but overall, a very basic setup is more than fine. Nearly all of my devices run Ubuntu/Debian, and only the work-related stuff gets over-engineered.
It's helpful for me to have something like a home lab where I can get hands-on experience with many different technologies. I've worn many hats, from developer to sysadmin, so a certain segment of my network tends to be built like Fort Knox. However, overall, 90% of my installs are minimalist with common best practices applied.
IMO a homelab for learning and a server that you're self-hosting services on really aren't the same thing and maybe shouldn't be treated that way, if you can swing it.
I'd rather my password manager or jellyfin or my peertube instance or whatever not be relying on a tech stack I don't entirely understand and might not be able to easily fix if it breaks.
I guess a lot of it is new to doing this vs greybeard split, since the longer I've done sysadmin work the less I care about the cool new thing and have a preference for the old, stable, documented, bugfixed, supported, and with a clear roadmap software.
I should probably get a job doing sysadmin work for a bank, lmao.
2.What do you wish you would have known as a beginner starting out?
Caddy. Once you try Caddy there's no turning back to Nginx or Apache.
Apparently traefik might be better if you run docker compose and such, as it does auto-discovery, which reduces the amount of manual configuration required.
That's what everyone thinks for a while, and then they go back to Nginx.
Eh, my main reason for switching is that Caddy builds in LetsEncrypt. My Caddyfile is really simple, it's just a reverse proxy that handles TLS and proxies regular HTTP to my services. I don't have it serving any files or really knowing anything about the services. Here's my setup:
- HAProxy - directs subdomains to devices (in VPN) based on SNI
- Caddy - manages TLS and LetsEncrypt and communicates w/ services over HTTP
- Nginx - serves files for things like NextCloud, if needed (most services have their own HTTP server)
Each of these are separate Docker containers, which makes it really easy to manage and diagnose problems. The syntax for Nginx is more complex for 1&2, and the performance benefit of managing it all in one service just isn't relevant for a self-hosted system, so I use this layered approach that makes each level as simple as possible.
I'm currently in the process of separating the certificate renewal service from the reverse proxy completely.
But if you're just starting out Nginx Proxy Manager makes it so easy.
Out of curiosity, what's the benefit of splitting those?
It lets you change reverse proxy or run a website with TLS completely independently of the certbot. The certbot deals with obtaining certs and leaves them in a dir, and the proxies or webservers just take them from that dir. If the proxy container breaks the certbot still does its thing etc.
It also makes it easier to do stuff like run different proxies in paralel for different things, chain proxies (for instance if you need to use a VPS because you can't forward ports) and so on.
But it's all for advanced setups, for basic stuff I'd still go with NPM.
Cool makes sense, thanks for the reply! And yeah, I don't think I'm quite there yet.