0:00 So, you might be wondering why you're looking at a 2012 Mac Mini right now. And that's actually because this was my first ever home server. And as you might expect, it had a lot of issues. I had no idea what I was doing back when I set this up. Oddly enough though, this little guy was still up and running up until just a couple of weeks ago when I finally decommissioned it. More on that in a bit. But as I was finally getting rid of this little guy, I was reminded of my first experiences self-hosting and all of the dumb mistakes I've made over the years, which sort of made me think, if I could go back in time and give pre-selfhosting me some advice, what would it be? I believe some of that advice might have been helpful for me, so it might be helpful for you as well. So whether you've been self-hosting for a while or are just now considering setting up your first home server, here are a few thoughts that I hope you might
0:45 find useful. Number one, you probably don't need as much hardware as you think you do. My computer experience before self-hosting primarily came from PC gaming and content creation. And for the most part in those realms, you want as much performance as possible. It's not uncommon that you might need a beefy system just to run your favorite game or edit in your necessary resolution and codec. But even if you do have a complete baller PC, more performance at least still means more frames or faster renders. So I think for a lot of people stepping into the self-hosting world for the first time sort of think the same. I mean, aren't data centers infamous for drawing gigawatts of power and demanding the latest and greatest hardware? Well, yeah, but in reality, a large majority of the services you're likely to be running at home will demand very little in terms of CPU performance and oftent times won't need a GPU at all. Of
1:32 course, there are exceptions. Obviously, if you want to do a lot of real-time video transcoding or run some big LM models or something, you'll need a capable system. But for the majority of applications and services that I think most people want to run, you really don't need a ton of hardware or really fast hardware. If you don't believe me, just watch some of the videos I've made on this channel. I love taking a look at older lowpowered systems, and by far one of the best ways to continue using those systems is by setting them up as full servers. If you're considering setting up your first server, but you're hesitant because you think you can't afford a powerful enough system, don't let that hold you back. In my experience, if you don't know whether or not your system will have enough horsepower, odds are it will. If you find out later on as you add more services that you don't have enough RAM or a fast enough CPU, then you can always upgrade over time or just migrate to a new system. So, my advice would
2:18 just be to get started with whatever you can easily scrape together and go from there. All right, number two. things are going to break and it's probably going to be your fault and that's okay. Knowing and accepting this is good because it's going to help you plan out your approach to setting up servers and managing them. It's easy to get really excited about a new application or project that's going to let you cut out a paid service or make your life more streamlined or whatever. So, it can be really tempting to follow a guide or a YouTube video, throw something together, and then just start using it. And sometimes this works out okay, but often times as you tinker with things a bit more, stuff starts to break. And if you live with family or roommates, well, this can start to annoy them as well. Trust me. So, one bit of advice I would have given my younger self would be to have separate environments for testing and production. Now, when you're just
3:05 getting started, basically everything is going to be testing, and that's great. Try things, break things, have fun. But whenever you want to continually use a service, especially if you want to ask your family to use that service, you're going to want to make sure that it's at least well less likely to break. And one way to help with that is to have a separate production environment. This can look very different depending on what your setup is and what you're looking to accomplish. Things are kind of a bit weird for me. I'm very fortunate to have access to lots of random hardware as part of my job. So, the majority of my testing gets done on the assortment of PCs that I get to tinker with. All of the important stuff that I run and use on a regular basis lives on pretty much a single Proxmox server. And I usually don't change much there unless I need to. And I always make sure that I have a good backup before I do. For some people, having multiple physical systems could work
3:51 really well. Like you might have one or a couple of systems that run your actual production services, but then have a completely isolated home lab setup for testing, experimenting, and learning. Or if maybe you just have a single system, you might just have separate virtual machines for production and testing. This is one of the reasons why I love running a hypervisor like Proxmox. Regardless of how you actually do it, I think you will benefit from having some sort of clearly defined separation between testing and production. Even if it's more so just to help with your approach to how you set things up and manage stuff. Now, sometimes, as much as I love self-hosting, I think it's also wise to determine when self-hosting is not the right option. For example, telling your wife that you canceled all of your subscription services because you just watched a jellyfin tutorial 30 minutes ago is probably not the best idea. Deleting all of your important
4:37 backups from Dropbox because you decided to build a DIY Trina server for the first time also probably not a good idea. Trying to host your business's WordPress site on a 2012 Mac Mini when you know very little about network security or web deployment. You get the idea. Now, speaking of that last example, if you are struggling to host your website and you're looking for a much easier, faster, and reliable option, you should definitely check out today's sponsor, Kinsta. Managing your WordPress site should be simple, and Kinsta does just that. Starting with their dashboard, it's intuitive and simple, while also giving you all the tools and analytics you need to manage your WordPress sites, databases, and applications. With Kinstub, you can also enjoy peace of mind that your site is protected and reliable. With two enterprise level firewalls, DDoS protection, a containerized architecture, SOCK 2 compliance, and
5:22 more. And with a 99.99% SLA backed uptime guarantee, you can feel confident that your site will stay up and running. But even if something does happen, Kinsta has excellent support with Oh man, this is so refreshing to say. I'm so tired of saying that everything is AI powered, but not here. You'll have quick access to an expert team of real human people that can help you solve even the trickiest of problems. Plus, Kinsta is fast with features like edge caching and early hints, 37 data centers, and over 300 CDN locations, Kinsta could deliver your site up to 200% faster when compared to other platforms. If you just want to make sure that your site is quick and reliable without all of the other hassle, definitely consider Kinsta. And if you're switching from a different platform, no worries. They'll handle the migration for you. So, give Kinsta a shot. You can actually get your
6:08 first month for free, plus a 30-day money back guarantee. Just click the link in the description or scan the QR code on screen to get started. All right, moving on to number three, and this is a big one. I would have told my past self to spend time learning networking. At the end of the day, everything that you're self-hosting is going to be connected via networking. It's the glue that holds everything together. But, well, oftent times, it's not as exciting to deal with. However, if you have a solid understanding of at least the basic core principles of networking, your self-hosting journey is going to be much more enjoyable. When it comes to setting up a particular service, odds are you'll have access to great documentation and a plethora of helpful YouTube tutorials and blog posts. But often times, those docs and guides are going to assume that you understand networking. And if you're going into it blind, you might find
6:54 yourself frustrated and lost and possibly just give up. I get a lot of troubleshooting emails and more often than not, the issue seems to be related to networking. So, if you're wanting to do any self-hosting, I think it's probably wise to have a good grasp on basic things like IP addresses and subnets, DNS, routing, etc. I'll post a link below to a great resource I found called Linux Journey, where if you work your way through the entire networking section, I feel pretty confident you'll walk away from it at least having a much better understanding of networking. There is one thing that that website doesn't really cover though, which is the concept of VLANs. VLANs specifically are something I wish I would have implemented much earlier on. Uh, if you're unfamiliar, VLANs or virtual LANs are virtualized separate networks that exist within your network. I'm not going to go into much detail on how they actually work in this video, but they
7:40 can not only help with security, for example, by isolating less trusted devices into their own network, but they can also just help with keeping things a bit more organized. Even when I just had a single home server, I kind of wish I would have started setting up VLANs then because, well, it's much easier to do it early on when you have fewer devices to deal with. I also would have told myself specifically to not just start poking holes in my firewall to access services from outside my local network. It's much more secure to use a VPN like WireGuard or something like Cloudflare Tunnels to expose your services externally. Fortunately, I didn't learn any lessons the hard way here, but well, things could have gone a lot worse. All right, speaking of specific things to learn, I would have told myself to learn Docker and to really learn Docker. If you've ever looked into self-hosting at all, you've probably found that Docker is
8:25 used quite extensively. When I didn't know much, I didn't quite understand why this was the case. I would watch some tutorials and sort of understood the basic concepts of what was going on, but it seemed like a lot of work. In my head, if you wanted to run an application, you would just download it and run it. You didn't have to set up a container with an image and bind mounts and networking and environment variables. But had I understood why containerization was so helpful, I probably would have learned how to take advantage of it much sooner. If you're like how I was and you didn't quite know why you should use Docker, let me explain some of the benefits of containers. Because containers are isolated environments with their own file systems, if you break something in one container, it's much less likely to affect other containers. You could get this isolation by running virtual machines, but containers are much more lightweight in comparison. An old crappy
9:11 PC can probably get by running a handful of containers, but if you tried running a handful of virtual machines, things would probably just grind to a halt. Also, because Docker containers contain all of the code and dependencies needed to run your desired application, it's really easy to just spin them up quickly or migrate containers to a new system. The only thing you would need to spin up a new container or copy it to a new computer is your configuration and any necessary data that the container needs. But trying to just run a bunch of containers via the command line can get really messy. And well, that's definitely something I was guilty of when I first set this guy up a few years ago. Rather than just using the command line, I would have been much better off had I used something like Docker Compose instead. With Docker Compose, you just write a configuration file which can include a single container or multiple related containers that might need to work in conjunction. Then you can just easily start up, stop, and apply updates
9:56 to the config with just a simple command. Now, I don't really use Compose all that much currently. I typically prefer to use something called Portainer to manage all of my containers, specifically the stacks feature. But Portainer stacks are essentially just Docker Compose. Using something like this helps keep things much more organized. And speaking of which, the fifth thing I would have told myself is to just stay organized. This has by far been the thing I've struggled with the most. And this also brings me back to why I only recently was able to get rid of this old Mac Mini. When I worked at my previous job before doing YouTube full-time, I helped put together a simple Slackbot for my team. It job was very simple, but it was also very important for the team's workflow. And this probably would have been a great example of a time where self-hosting just wasn't the best option. But anyway,
10:42 I decided to run the app in a Docker container on that old Mac Mini at my house. And well, it actually worked really well up until the point where I quit. Obviously, it wouldn't make sense for me to keep hosting this when I don't work there. So, I made plans to try and migrate it over either to a cloud service or for them to just host it on their own systems. However, when I originally deployed it, I didn't document anything. And because I'm a janky wannabe coder at best, figuring out how to properly redeploy this wasn't wasn't straightforward at all. It also didn't help that the repo with the source code and my access to Slack were all tied into my old deleted work email. But anyway, it was definitely solvable. I just knew I was going to have to set aside some time to sit down and figure it all out and make sure we could safely migrate it somewhere else. And well, it it was working, so it was never really a
11:29 priority. And well, you know how it goes. The temporary fix of me just continuing to run it for them became the permanent fix. Now, obviously, I finally got around to migrating that off of this and I could finally shut down and get rid of this little guy. But that took like 2 years. Had I just clearly documented things early on or just had a better system of how I deployed things rather than just a hodgepodge of containers scattered across different systems, I probably would have just fixed the problem right away with no issues. So yeah, find ways to stay organized. Now, once again, organization is going to look different for different people, setups, and use cases. Maybe it's just a simple note or doc where you keep notes of how you set things up and what changes you've made. Or for other people with huge setups, you might need detailed network diagrams and an entire wiki just to properly document things. And then some super nerds have their
12:14 entire infrastructure just defined in code using Anible or Nyxos. So well it sort of documents itself a bit. Now sadly I am still pretty unorganized. But eventually one day I'd like to get some good documentation set up and try to keep much better notes of how things are configured in my home lab. But well that's on pause for now because well I'm about to be moving. Whenever we move into the new house I'm planning to pretty much rebuild my entire home lab from scratch. I'm hoping that clean slate will be a good starting point for some good documentation and some better organization, but we'll see. It's probably going to still end up being a cluttered mess at the end anyway. Anyway, you know how I said we had five things? Well, there's actually a surprise. I have a bonus one. And well, really, it's just cuz I didn't think six things sounded good in the title and five things sounded better for some
13:00 reason. Anyway, the last thing I would have told myself is that there are no right answers. You'll see tons of videos and Reddit threads and blog posts out there talking about some incredible new container or configuration that you need to use or or whatever and be tempted to look at that and think that what you have isn't right. Especially for someone like me that doesn't have any sort of professional IT experience. But the more I've gotten into self-hosting and the more I learn, the more I've sort of realized that even in the professional realm, there are a million different solutions to a problem. And I think when I was first getting started, I was tempted to hop around from one thing to another because, well, I assumed that what I was currently doing was wrong. Whenever you're presented with a different way of doing things or some new software, you might be unsure of whether or not it's right for you and trying to determine that could be sort of tricky. But if you find it
13:46 interesting and just want to spend the time to learn it, heck yeah, do it. If not, though, ask yourself, does what I already have do this thing just fine for me? And if so, you're probably fine to just not worry about it. If you don't have something that already solves that same problem or you're not happy with your current solution, then it might be worth exploring. At the end of the day, it's your servers and your network and your home lab and most importantly your time. The right way is whatever works well for you. I know this video was definitely a bit different. It's just me sort of rambling on. If I'm being honest, since I am moving, I'm kind of looking for some video ideas that don't involve as much testing and filming of B-roll because, well, there's a decent chance that by the time you're watching this video, I'm already trying to pack up this whole studio to get ready to move. So, please forgive me. But I really do hope that at least maybe one of these thoughts might be beneficial
14:32 for you and your own self-hosting journey. If so, let me know down in the comments. Also, if you have any advice, put that down there as well. We might all be able to learn from it. That's about it for this one, though. So, as always, thank you guys so much for watching. Stay curious and I can't wait to see you in the next one.
