Published Aug 29, 2026, 7:00 PM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. Self-hosting services is an easy pitch to anyone who likes to tinker, and getting into it as a hobby has never been easier. Swapping a few recurring bills for a bit of effort spread across time sounds like a good trade, and it is, but it's not all positive. I've been running an assortment of self-hosted FOSS tools for over a year, and these are the day-to-day and setup annoyances that nobody warned me about. Updates are a real task, and they're not automatic They don't always break things, but it's not like updating your PC Installing the service is one thing, but maintaining it is another thing entirely. Self-hosted projects ship changes on their own schedule, so the chances that something breaks when you update is really high. For example, a service that I and many others run, Immich, has it in their documentation loud and clear: it tells users that the project is under heavy development and to read the patch notes before updating. That's the norm for the vast majority of FOSS services, and it's not just down to what you see in the app either. Running with the Immich example, they recently moved the server's internal port from 3001 to 2283, which would break your setup unless you made edits to your Compose file and the reverse proxy in front, if applicable. Getting access to your stuff remotely is its own project It's easier than ever, but it's still a project Most guides you'll follow for self-hosting stop at localhost, and that's fine for many. Reaching your services from anywhere, however, is another story entirely, and it means choosing between port forwarding with a reverse proxy, an overlay VPN, a relay through a VPS, or a combination of those approaches. None of those are obviously correct for a beginner, and it compounds if you're behind CGNAT. Whichever route you pick, you've now taken on the burden of TSL certs, DNS records, and other configurations that accumulate as you add more services. I've opted for a self-hosted mesh VPN on my VPS, which is the best of a lot of worlds: I control every part of the stack and don't rely on an external cloud service for my control plane, but still maintain the ability to host things with a reverse proxy, thanks to NetBird's newer updates. Storage fills up quick They don't warn you about this You plan capacity based on the amount of data you want to store, but what actually fills the drive is everything that's generated around it. Logs are the classic killer, but snapshots, local backups, preview files, caches, indexes, and many other things can pile up fast if your pool is small. This becomes more of a non-issue once your pool is large enough, but it's still worth going through these things and purging them every once in awhile. These projects can disappear Maintaining is usually up to a small group of people, and they can stop at any time FOSS is excellent for so many reasons, but one of the biggest downsides to relying on it in your daily workflow is the fact that it can basically disappear at any given moment. When the people (or person) maintaining it decides they're done, you're relying on someone else to pick up the mantle if you can't do it yourself. Booklore, a self-hosted digital library platform with more than 10,000 GitHub stars and thousands of daily users, disappeared without warning, taking its repository, Discord, and website with it. Users only found out when they tried to update or pull the container and hit a 404. It's not a freak accident either, and it's just a consequence of how the ecosystem works. Most open source maintainers are unpaid, so the moment they want to stop maintaining, they probably will. In the case of Booklore, it was forked almost immediately into Grimmory, which is now maintained by former contributors. That's something that proprietary software wouldn't be able to match. FOSS Other people probably depend on you now It's a very real consequence of hosting anything As someone who took on the responsibility of hosting and backing up all the photos and documents for my family, I feel this one personally. It is obviously much easier to pay X dollars a month for a storage subscription and let a third-party deal with the rest, and that pull is what ends self-hosting hobbies. The moment you have to take something down for maintenance or something goes down on its own, you're now responsible for getting things back online, and usually it's not something you can defer to the following weekend. Before taking on responsibility like that for others, I'd recommend streamlining every service as well as possible first, weeding out any potential quirks that you might be able to deal with, but a real end-user would complain about FOSS services are excellent Over a year in at this point, the advice I'd give to anyone starting is actually quite short. Pick a couple of services, max, then run it for a few months before you add more, and learn how to restore everything from a backup before you trust it with anything you can't replace. A service being free and open-source doesn't automatically make it great, but there are a plethora of them that are simply unbeatable for self-hosting.
A year into self-hosting FOSS, and nobody warns you about these operational nightmares
Full Article
Original Source
Read the full article at Xda-developers →KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.