Self-hosted applications may sound like a hassle to set up, but they’ve got plenty of benefits over their cloud-based counterparts. Since the services as well as their data remain on a local server, you don’t have to worry about third-parties getting their grubby hands on your private information. Likewise, deploying your own app instances can save you quite a bit of money in the long run, as you don’t have to pay frequent subscription fees to unlock paywalled features.

In fact, I’ve been running password managers, media servers, and a handful of other essential services on local machines for the last couple of years. While I do encounter overly complicated services from time to time, I can confirm that it’s easier than ever to deploy your own apps these days. So, here are some quick tips from yours truly to help you find your way through the vast and interesting world of self-hosted services.

Use old machines and budget-friendly devices

Instead of breaking the bank on new hardware

Confession time: I’ve been drooling over server rigs ever since I was a teenager, and truth be told, that’s probably not going to change even though I managed to get my hands on a Xeon system. However, normal PCs are more than capable of deploying multiple services without breaking a sweat, and you can even repurpose old laptops as reliable self-hosting workstations.

That’s because most of the popular self-hosted apps run inside containerized environments, and barring certain exceptions, they aren’t all that taxing on your hardware. But if you don’t have spare PCs lying around, you can grab a mainline Raspberry Pi board and host dozens of apps on it. Or, you could even set up container runtimes (or better yet, containerization platforms inside a Type-2 hypervisor-based VM) on your daily driver and experience the thrill of running FOSS apps locally. While we’re on the subject…

Start with a containerization platform

Before transitioning to Docker/Podman + Portainer for advanced workloads

As someone who started his self-hosting journey with a CasaOS instance, I’m a fan of containerization platforms and even use some to this day. Besides featuring sleek UIs, CasaOS, Cosmos, Runtipi, and other popular platforms also let you use simple toggles, menus, and options to whip up new containers. Plus, they’re compatible with hundreds of cool self-hosted services, and even ship with extra networking and security-related settings to make your container management tasks a lot easier. Better yet, many of these containerization platforms are meant to run on top of an existing OS without requiring bare-metal setups, so you can even host them on your daily driver.

Once you’ve gotten familiar with how containers work, you can start using dedicated runtime environments. Docker is fairly easy for beginners, and you can even go for its Desktop application if you don’t want to start off on the CLI-heavy deep end. Portainer is another neat tool worth checking out, as its menu-driven interface provides even more options for managing your containerized services than Docker Desktop.

Document everything

Make troubleshooting easier for your future self

As you start hosting more and more services, the complexity of your setup is bound to increase. You’ll have more port numbers to remember, container images to keep track of, SSL certificates to manage, and broken updates to worry about. As if that’s not enough, containers are rather fragile – to the point where a single edit in the wrong file can end up breaking them. There’s nothing wrong with that, since breaking your containerized environments can be a great learning experience.

That said, it’s always a good idea to document your projects. If things go wrong, you’ll have your notes and diagrams to fall back on, so you won’t have to go through the same mental gymnastics as when you initially configured everything. Me? I keep a Trilium Notes container on a separate server (which also houses my monitoring services) and even use the articles I’ve published here on XDA for reference whenever I have to redeploy my app stack.

Set up Tailscale for remote access

Especially if your network is cursed with CGNAT

Before I talk about Tailscale, I must admit that it’s not a fully self-hosted solution, as I have to rely on company servers to connect to my nodes. However, it’s my favorite tool for remotely accessing my self-hosted arsenal, as it’s not only free to use, but also offers extra security options to prevent anyone else from entering my home network. Plus, my local network is afflicted by the curse of CGNAT, which makes self-hosted VPNs a lot harder to configure.

If you're free from this scourge, you can even try deploying your own VPN server to securely access your service stack from external networks. WireGuard works very well for the task, though you can also set up Headscale to create a self-hosted control server for your Tailscale nodes.

Schedule backups as often as you can

Even a few snapshots are better than nothing

Check the forums for any PC-related hobby, and you’ll often hear the community members recommend backing up your system every once in a while. Since you’ll end up relying on your self-hosted arsenal for everyday tasks, keeping dedicated backups of your essential containers lets you minimize downtime if (or rather, when) things go south.

But if your self-hosting setup lies at the budget-friendly end of the pricing spectrum, you don’t have to go out of your way to grab a dedicated NAS. Kopia makes backing everything up a cakewalk, and since snapshots don’t consume a lot of space, you can just store them on any machine in your home lab for safekeeping – including your daily driver.

Above all else, self-hosting is a lot of fun

Besides the obvious benefits of running everything locally, self-hosting your own containers is a fun hobby. I often browse through GitHub repos in search of cool services just to satiate my curiosity, and I’ve come across everything from criminally underrated apps that deserve more attention to borderline unhinged ones that bring quirky (but just as useful) features to the table.