For the uninitiated, this post is about building up a collection of technology to learn how things work or meet certain needs, so “homelab” in this case is referring to something that people in the IT space frequently build out and/or own. If the idea sounds neat, there are about a million tutorials on how to actually build a homelab and one of these years I’ll compile a list of some of those resources I feel are legitimately good strong starting points for your journey that explain things in a way that’s easy for novices to understand, but that’s not this post. No, since there are so many places you can start for myriad personal reasons and numerous resources to feed those needs, I wanted my contribution to the conversation to be something that I feel more qualified to provide, and that would be a grounded resource to help you understand what a homelab is and where the journey of making one really starts.

A “Homelab” isn’t any particular piece of hardware nor is it software. The real Homelab starts with a mentality; either a desire to learn how to make effective use of some technology or a deciding to solve a problem with technology.

I feel like the most important thing people miss when trying to convince others that they should start the journey to build a homelab is that there is no one-size-fits-all proper approach to building a homelab because it’s such a deep, personal experience. If you’re a content creator, there’s a clear and obvious incentive to creating a homelab, as your data, the content you create, has value to it in both a personal pride sense but also in a business, money-making sense. Learning new software to better protect it and investing in hardware to increase how much you can store are smart business investments, but most people aren’t content creators. They might be gamers or work a standard job where they want their computer to get out of their way so they can enjoy their free time; people in these demographics wouldn’t have the same needs or desires, thus offering those as motivations to start a homelab wouldn’t be persuasive.

There’s also the problem that a lot of people that make content on building homelabs are already hip deep in research in how things work or have been working in the IT space for a bunch of years prior to making guides and resources and suffer a pretty common problem related to IT people making documentation; we spend so much time involved with specific, ubiquitous concepts that we end up writing documentation for our peers and not for the general public (or even technical peers in other ways). Notice I include myself in that demographic because it is a weakness I also suffer.

Let me give an example of what I’m talking about; we started using a piece of software at work that automatically checks certain things in our code before we can deploy that code to use in our production environment. One of our deployments failed a check and when I looked at the logs, I completely understood what they said, but when I tried to relay my findings to my colleagues, they didn’t understand what I was talking about. While these are my coworkers and they are competent at working on the things we’re required to work on to support the process we’re responsible for, the backbone of this software that checks our code was running on a Linux backend and there was a way to see the command line output of the process as it ran, which is not normally something my team would deal with in their normal course of work. I have worked extensively in Linux command line environments for over a decade at this point so reading the inputs and understanding the outputs was second nature to me by that point, but my coworkers had limited to no experience, so the terms I used were completely foreign to them. What happened there is that I had assumed that since we all worked in the same area, we all would have the same experience, except I learned the Linux command line interface as a tool back when I was interested in Linux in high school, installed it alongside Windows in a dual boot configuration on my laptop, and learned I could do anything I set my mind to using the command line. That personal experience led to my knowledge, not work, so my assumption that they would have the same or similar knowledge was obviously just wrong, and these were my peers in a work environment where I’m actually one of the youngest team members; many of my colleagues have been working in this field with these technologies for about as long as I have been alive, but haven’t had a reason to look under the curtain so to speak.

As I said, this happens a lot. While “Information Technology” is considered a field of work, there’s actually a tremendous amount of variation within that field, so much so that saying “I work in IT” is actually meaningless to anybody that has an even passing understanding of how wide the field is. To give an example, a Library Technician is technically IT, and may need to know how computers network to set up stations for people to look up books so the stations can connect to the server that hosts the software that keeps inventory of all the books in addition to what is and isn’t checked out, but doesn’t need to understand the fine details of packet routing that a Network Administrator would need to know or how to route traffic to meter egress and ingress that a Cloud Compute Architect would need to understand. A Software Engineer that develops that software the Library Technician uses may not even need to understand how networking works if they offload that processing to a micro-service they can invoke and interact with via an API. In that same vein, the Developer, Architect, and Admin probably have no idea what kinds of equipment people doing Audio/Video work deal with or why you’d use certain equipment in specific situations. All these positions can be generally placed under the umbrella of “IT” but require wildly different skills and knowledge even when they’re pretty well immediately adjacent to each other. So even when talking to other IT folks, there’s no guarantee we all have the same common language.

This phenomenon shows up in the homelab tutorial space in that people experienced with general IT concepts will gloss over them when setting up tutorials, so somebody like me with similar enough experiences can work from their guides no problem while a novice that doesn’t know the simple 20 step process they’re assumed to understand that’s required to make this thing work will get lost and frustrated. In my experience, even if people do make guides on these basics, there’s this assumption that either you’ve seen that older content thus should understand it for all projects moving forwards from that point, but more often I feel like the issue is that they did research and understood the concepts well enough to meet their needs, but they forget that it was a critical step required to accomplish their goal so they omit it making following them challenging for somebody that’s inexperienced.

All that said, this post is intended to give you a place to start on your homelab journey; a position that is far more ubiquitous than saying you need some piece of hardware or software that will help guide your decision making. It is also to give a realistic understanding that finding and implementing solutions can and will take a lot more work than some people will realize and convey.

So Then, What’s This “Homelab Mentality”?

I actually love the way one of my managers explained our role in an organization as Information Technology; IT is a liability that does not produce value on its own. IT’s value is in its ability to improve other areas of the business. In a business sense, the actual business is what earns money, and IT solutions enable the business to be more productive and earn more money. IT should make work easier, faster, more secure, or improve it in other ways. The “Homelab Mentality” starts with either a desire to learn or a problem to solve. Some people like myself have a desire to understand tools and systems so that we can reference that knowledge and experience later when necessary and that’s all the motivation we need to start a homelab. Most people need some other type of motivation, and solving problems can be a big motivator so long as the total cost of the solution (time invested in learning hardware/software, monetary cost of hardware/software, and complexity/ease-of-use of the hardware/software) generates more value than not going through that journey. To iterate it again, IT is a liability that does not generate its own value; the value is based on how much of an improvement people experience. This is why there is no universal starting point and why a homelab is such a personal experience; each person is going to have a different set of values and metrics for how important each is to them.

So going back to our starting examples, while a content creator may be interested in storage space generally to store more content or store copies of their content as backups, a gamer may be a lot more willing to simply uninstall games they aren’t actively playing as a space management strategy, so that’s not going to motivate them to start a homelab. What may interest a gamer is to know that there are routers with Quality of Service (QoS) features that can prioritize game traffic which can have a pretty substantial reduction of lag depending on network conditions, so changing routers from whatever default equipment is supplied by your ISP can have a pretty big and meaningful impact on your gaming experience. Setting up a test system or few with metering software and a dedicated space to test different routers or even different firmware on routers. Well then, what about our day job person that just wants to watch television or relax after a hard day of work? I mean, there’s a motivation there that they might not be aware of as well; if they watch television and have shows they love but can’t watch because they’re on late at night or when they’re working, there are Digital Video Recording (DVR) solutions that can be used to record those shows on a schedule using a computer. Buying an old system to use as a test and configuring a TV tuner may be a worthwhile investment if you can configure it to record your favorite TV shows to watch back at a later date, maybe even via a streaming platform like Plex so you can watch it at any time on a personal device.

Obviously there’s lots of potential, but that investment versus reward is an important metric; not everybody sees the same value in any specific outcome, and it’s important to respect that. Regardless of the approach you decide to take, whether it’s solving specific problems or learning new technologies, the key part of the mentality that’s important is a desire to learn. You need to want to learn more than whatever obstacles will and could stand in your way (knowledge barrier, technology barrier, sometimes scripting or code will need to be written). As long as you are determined to learn, there are many approaches you can take to starting your homelab journey and often many different solutions that can meet your needs (often with varying strengths or weaknesses), but the correct answer is always the one that best suits your specific needs, and it’s important to remember that. No need to go out and spend thousands of dollars on the best hardware if something “mid-tier” suits your needs and growth just fine, no need to learn all about how networking works if you only want to understand DNS for some routing tricks. That said, wanting to learn how all of the dials work so you know which to press when is also a perfectly acceptable approach. The path is your own to forge so long as that desire to learn keeps burning.