Intro to Self Hosting
So you want to get into self hosting? It’s a fun way to learn a lot of IT concepts, and if you don’t mind break/fixing, it’s worth a try.
What do I need?
- A server. What you bring to the table is going to decide quite a lot about how much you can handle simultaneously, and what operating systems you can use. My current main machine was one I got for a song in a company discard, so it’s a Xeon w/ 16 gigs of ram and a terabyte in drive space. For the introductory user, that might be overkill, and I know folks who’re perfectly happy with a Raspberry Pi. I prefer Intel machines purely to keep some options open.
- A basic understanding of TCP/IP Networking. Generally speaking, everything you host is for the purpose of accessing through other machines, and so you need to know how to do things like:
- Forward a Port through your router
- Understand what DNS is
- Understand the difference between internal and external IP addresses
First decisions:
Am I going to allow the outside world to access my services?. This is a very important decision to make, and it’s one that novices tend to low ball to their peril. The internet is a dangerous place, filled with folk who will tear down the things you build out of spite, or take advantage of your trust to steal from you. However, a zero outside world access lab does introduce some problems, like eliminating some serious quality of life elements like LetsEncrypt TLS certificates. Depending on your tools and experience, you can get around some of this by only hosting http in house, or rolling your own Certificate Authority. I’ve been very pleased with splitting the difference by using Nginx Proxy Manager’s traffic rules to allow only certain services access from the outside, and blocking others.
First Steps: Your Router.
You’re going to want the ability to define hostnames (example, ‘music.mylab.org’). You could go dirt simple and edit host files, but that doesn’t make it easy to use if you have multiple devices that will access the things you host. If your router has the ability to define host names, then that may be good enough for you! I am using a service called PiHole. This allows me to not only define hostnames quickly, but to also subscribe to blacklists to block ads, filth, etc. I set my router to use the PiHole instance as its own DNS server, and as the address to provide to DHCP clients on my network. Works like a champ. Remember, folk on your network can always switch out the DNS server provided to them for their own choice, so as security goes, this is a thin layer to your onion.
My PiHole instance is a docker container running on my server, which made it somewhat easy to stand up and back up. You don’t have to do that; you can install native, or get a Raspberry Pi. Personally, I am crazy about Docker for home labs because you can do break / fix work very, very quickly. I run docker commands from shell straight from SSH to the server, but there are installations that you can use to make this easier. Ain’t no shame in that; there’s a lot of implicit knowledge here already, and the longer it takes you to get a service running, the higher the odds that you’ll tap out.
Next Steps
I found that Nginx Proxy Manager was the bees knees when it comes to how to handle accessing a service I’ve stood up. Say, for example, I want to stand up a Jellyfin (great for media serving) server. I open PiHole, and set ‘jellyfin.mylab.org’ to point to the IP address of my lab server, say 192.168.1.5.
Next up, I open Nginx Proxy Manager and I map that hostname, jellyfin.mylab.org, to 192.168.1.5 on tcp port 8010.
I set up my docker container for jellyfin (say it listens by default on port 80, but I can’t do that, because 80’s already being used for Nginx Proxy Manager) to map port 8010 to the port 80 for the docker container. You start the container, open your browser, and visit http://jellyfin.mylab.org. PiHole directs your web client to the proxy manager, and the proxy manager uses a reverse proxy to connect to 192.168.1.5:8010; net result, you are looking at your first login. Yay!
Now for that jellyfin instance to actually see your media, you need to provide a volume map. If, for example, your music’s all at /mnt/Music, and if Jellyfin wants to see that from it’s perspective as /var/media, then that’s -v /mnt/Music:/var/media. Docker always handles maps for ports and volumes with the host machine’s path or port, a colon, and then the relative version inside the container.
Implicit knowledge
I see after saying all of this that I’ve made a great many assumptions about you. I’m assuming you are using Linux and know how to get it installed. You don’t HAVE to do that; it’s possible to run Docker straight out of Windows, but it’s a pain.
I’m assuming you have a spare machine. You don’t have to; you could install VirtualBox, or use Windows Hyper-V, and run Linux as a virtual machine off of your Windows PC. You could use UTM or Parallels if you’re rocking a Mac. Up to you.
I’m assuming you know how to mount external file systems on that Linux box. You don’t have to; if you have the disk space, you can host your files on the server machine.
Now, here’s the thing about EVERYTHING we’ve said so far; none of it’s the “right” way. The whole idea behind getting into this is to try different things; my workflow now doesn’t look anything like where I started, and I would bet you good money that it’ll look radically different a year from now. This is just what works for me now, which is both more and less complicated than what I used to do.
Was this helpful? Let me know; I love talking about this stuff!