I saw this post today on Reddit and was curious to see if views are similar here as they are there.
- What are the best benefits of self-hosting?
- What do you wish you would have known as a beginner starting out?
- What resources do you know of to help a non-computer-scientist/engineer get started in self-hosting?
- 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.
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 just moved everything from vultr to self host because of their latest changes.
EDIT: As I suspected, the changes that u/mesamunefire is referencing are the ones that taken out of context awhile back and incorrectly assumed to apply to user VPS’ and the data on them, which is not the case. Those terms only apply to information posted publicly to their website, like the community forums.
What changes would those be
https://old.reddit.com/r/webdev/comments/1boz5ne/vultr_new_tos_claims_all_commercial_rights_to/ " You hereby grant to Vultr a non-exclusive, perpetual, irrevocable, royalty-free, fully paid-up, worldwide license (including the right to sublicense through multiple tiers) to use, reproduce, process, adapt, publicly perform, publicly display, modify, prepare derivative works, publish, transmit and distribute each of your User Content, or any portion thereof, in any form, medium or distribution method now known or hereafter existing, known or developed, and otherwise use and commercialize the User Content in any way that Vultr deems appropriate, without any further consent, notice and/or compensation to you or to any third parties, for purposes of providing the Services to you."
And you could not opt out. You had to click agree in order to login. That’s the biggest one.
It was later removed after the fact but there were other changes that sucked.
That only applies to posts on their forums. Not the content on your VPS
Nope. It’s the content.
Incorrect. It applies only to the forums. It does not apply in any way, shape, or form to your VPS or the content on it. It’s one thing to be mistaken, but let’s not spread misinformation on purpose.
A Reddit post incorrectly took portions of our Terms of Service out of context, which only pertain to content provided to Vultr on our public mediums (community-related content on public forums, as an example) for purposes of rendering the needed services – e.g., publishing comments, posts, or ratings. This is separate from a user’s own, private content that is deployed on Vultr services.
Since our inception, Vultr has been committed to upholding and adhering to the strictest data privacy and protection standards across the world (including HIPAA, GDPR, and DPDPA). Our customers own 100% of their content.
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)
Are you still on Hetzner? How’s their customer support in general?
Yes, correct.
I apologize if someone misunderstood my reply, Plex was the bad actor here.
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.
Benefits:
-
Cheap storage that I can use both locally and as a private cloud. Very convenient for
piracystoring 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.
-
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.Is containers here used in the same context as docker? I’m not familiar with podman.
Just about but it’s more experimental.
It is much easier to buy one “hefty” physical machine and run ProxMox with virtual machines for servers than it is to run multiple Raspberry Pis. After living that life for years, I’m a ProxMox shill now. Backups are important (read the other comments), and ProxMox makes backup/restore easy. Because eventually you will fuck a server up beyond repair, you will lose data, and you will feel terrible about it. Learn from my mistakes.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CGNAT Carrier-Grade NAT DNS Domain Name Service/System Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol NAS Network-Attached Storage NAT Network Address Translation NFS Network File System, a Unix-based file-sharing protocol known for performance and efficiency PiHole Network-wide ad-blocker (DNS sinkhole) Plex Brand of media server package RAID Redundant Array of Independent Disks for mass storage SMB Server Message Block protocol for file and printer sharing; Windows-native SSD Solid State Drive mass storage SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) ZFS Solaris/Linux filesystem focusing on data integrity k8s Kubernetes container management package nginx Popular HTTP server
20 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.
[Thread #899 for this sub, first seen 30th Jul 2024, 23:35] [FAQ] [Full list] [Contact] [Source code]
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.
deleted by creator
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.
deleted by creator
This is going to be a bit of my grumpy-greybeard, but again: if you’re learning, then something like Docker and docker-compose is much simpler and less prone to fuckups than a bunch of K8s.
If you don’t know ANYTHING about what you’re doing, starting with the simplest tools and then deciding if you want to learn the more complicated ones is probably a less insane path than jumping right into the configuration-as-code DevOps pipeline.
And, at that point, you should have your “production” and “testing” environments set up in such a way they won’t eat each other when you do an oops.
btrfs with its send/receive (incremental fs-level backups) is already stable enough for mostly everything (just has some issues with raid 5/6), and is much more performant than zfs. And it is also in the linux kernel tree (quite hugely useful). Of course, if more zfs-like functionality is what you look for.
“Already stable enough”
- no it isn’t.
- if fucking should be, it’s been around 15 years!
NixOS is awesome!
Can you clarify on how NixOS is great for selfhosting? I was going to do mint.
you configure your whole server in one file (including docker/podman services), installation and configurations is taken care of by the package manager, you pretty much only need to know one file to admin your system
and no extra stuff is installed only what you specify so you have a minimal resource usage.
i think this is awesome
I would’ve wished
- don’t rush things into production.
- dont offer a service to a friend without really knowing and having the experience to keep it up when needed.
- dont make it your life. The services are there to help you, not to be your life.
- use docker. Podman is not yet ready for mainstream, in my experience. When the services move to podman officially it’s time to move. Just because jellyfin offers official documentation for it, doesn’t mean it’ll work with podman (my experience)
- just test all services with the base docker install. If something isn’t working, there may be a bug or two. Report if it is a bug. Hunt a bug down if you can. maybe it’s just something that isn’t documented (well enough) for a beginner.
- start on your own machine before getting a server. A pi is enough for lightweight stuff but probably not for a fast and smooth experience with e.g. nextcloud.
- backup.
- search for help. If not available in a forum. ask for help. Dont waste many many hours if something isnt working. But research it first and read the documentation.
Podman is not yet ready for mainstream, in my experience
My experience varies wildly from yours, so please don’t take this bit as gospel.
Have yet to find a container that doesn’t work perfectly well in podman. The options may not be the same. Most issues I’ve found with running containers boil down to things that would be equally a problem in docker. A sample:
- “rootless” containers are hard to configure. It can almost always be fixed with “–privileged” or some combination of permission flags. This would be equally true for docker; the only meaningful difference is podman tries to push everything into rootless. You don’t have to.
- network filesystems cause headaches, especially smbfs + sqlite app. I’ve had to use NFS or ext4 inside a network-mounted image for some apps. This problem is identical for docker.
- container networking–for specific cases–needs to managed carefully. These cases are identical for docker.
And that’s it. I generally run things once from the podman command line, then use podlet to create a quadlet out of that configuration, something you can’t do with docker. If you are having any trouble with running containers under podman, try the --privileged shortcut, see that it works, and then double back if you think you really need rootless.
For #2 and #3, it’s probably exceedingly obvious, but wish I would have truly understood ssh, remote VS Code, and enough git to put my configs on a git server.
So much easier to manage things now that I’m not trying to edit docker compose files with nano and hoping and praying I find the issue when I mess something up.
I know this is coming up on my radar, but I am not quite sure where to start. Might you have any resources on hand to point me in the right direction?
Especially once I have everything dialed in the way I want, I’d love to be able to pull from my own repo to get stuff running again/spin up a new instance
Honestly, I learned a ton from these guys: https://www.smarthomebeginner.com/
I’ve diverged a good bit since then of the services I’ve added and the specifics of how I configure things (I still use Traefik whereas I think they’ve shifted to Nginx), but they have a great example of a GitHub repo and what it looks like to manage a self-hosted server.
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.
