Posted on: 29 October 2026 | Last updated: 29 October 2026 | Read: 11 min read | In: Linux, Server, Automation, Networking
In this article, I talk about my experience building a home server, what I am running, and some recommendations based on my experience.
I always wanted to get a home server because of the convenience and learning opportunities it offers. With a home server, I could set up services that block ads, provide better storage for important documents, and allow me to self-host various applications that we use in our day-to-day lives.
In this article, you will find my hardware choices, how I configured the BIOS, tested the hardware, installed Ubuntu Server, and set up the services I am running. I'll also discuss my future plans for this project. This is not a guide on how to build a home server, but I'll share some advice from my experience.
Hardware choices are personal and depend on a lot of factors. The choices that worked for me might not work for others. If you are planning on building a home server, please consider the following:
Here are some things I would generally recommend regardless of your requirements:
With those out of the way, here is my hardware configuration:
My decisions were based on my budget and the fact that my personal computer already uses the same AM4 platform. If this project failed, the worst-case scenario was that I could upgrade my existing computer using some of these components.
The RAM was not my first choice because it was not from a brand that specializes in manufacturing RAM. That's why I ran some tests on it, which we'll discuss in the next section.
I also looked for second-hand PCs and components, but unfortunately, I couldn't find many options in my city. Don't let that discourage you, though. Chances are I was unlucky or didn't spend enough time searching.
Ideally, the SSD would only be used for the OS and services, so it would probably be enough for a long time. However, since I am also storing photos and movies on it, it will run out of space much sooner. I have plans to address this in the future.
You don't have to buy the same hardware as me. If you are planning to build a server yourself, you have plenty of choices. You can start with a simple Raspberry Pi, use an old laptop or desktop, buy second-hand components, or buy everything new. Do whatever fits your needs and budget.
In fact, I think it can be better to use separate hardware for separate services, depending on what you want to run. I'll discuss why I think this makes sense later in the article.
Finally, once the parts were sorted out, it was time to build the PC. This was one of the best parts of the project because I built it with my sister. I built my own computer back in 2018, and it was a lot of fun. I'm glad I was able to share the same experience with her. She enjoyed building the PC too!
My CPU was already supported by the motherboard, so I didn't need to flash a new BIOS. I checked and tweaked the following settings:
After that, I booted into Memtest86+ using a bootable USB drive. Memtest86+ is a memory-testing tool that helps identify problems with RAM. I wanted to run it before doing anything else because my RAM was not from a well-known manufacturer.
I used the default settings and ran the test before proceeding with the OS installation.
I installed Ubuntu Server using a bootable USB drive. Ubuntu Server was a natural choice for me because, as a software engineer, I already had experience using it on VPS instances.
If you are not comfortable using the terminal, you can also explore CasaOS, Umbrel, or similar projects. CasaOS, for example, provides a graphical interface for managing applications and services on top of a Linux installation.
For managing deployments and maintenance, I find the terminal simpler and more manageable than a GUI, so I didn't install CasaOS or anything similar.
After installing Ubuntu, I followed the usual practices for setting up a server. These included creating a non-root user, configuring SSH key-based authentication, disabling password authentication for SSH, updating installed packages, and installing the required tools such as Docker and Docker Compose.
I manage my applications using Docker Compose. I find it simple and manageable, especially when running multiple services.
I prefer pinning the versions of the applications I run instead of blindly using latest. This gives me more control over updates and makes deployments more predictable. However, pinning versions also means I need to keep track of updates and apply security fixes when they become available.
I also keep my environment variables in .env files and exclude those files from Git so that credentials are not committed to the repository.
My Docker Compose configuration files are backed up in my home-server repository. This makes it easier to review my configuration and recreate services if needed. However, these files alone are not a complete backup of the server or the data stored on it.
I haven't started using these services to their full potential yet, and I am still setting some of them up. All of these projects are well-structured and modular. As a software developer, I appreciate these projects even more and look forward to learning more from them.
If you want to review my Compose files, you can find them in my home-server repository.
| Category | Services |
|---|---|
| Network | Pi-hole |
| Dashboard and Monitoring | Homepage, Beszel |
| Photos and Media | Immich, Jellyfin |
| Media Automation | Jackett, Radarr, qBittorrent |
| Workflow Automation | n8n |
I have a lot of plans for this project and want to extend the setup further. Here's how I would divide those plans.
When I started this project, I thought I should build a single server that could do all of these things. However, I think it can be better to use separate computers for different tasks.
A single machine is cheaper and simpler to start with, and it makes sense when you are experimenting or running services that don't require high availability. However, separate devices let you choose hardware that best fits each workload and help isolate failures. If one machine goes down, services running on other machines can continue working.
For example, network services such as DNS filtering are useful only when they are available. Running them on a separate low-powered device means that a failure or restart of the main server doesn't necessarily take down the entire network. Having two devices can provide additional redundancy, although the services must also be configured to fail over properly.
Of course, running multiple machines also means more hardware costs, power consumption, and maintenance. I don't think every service needs its own machine, but separating services where it makes sense can be a better approach in the long run.
I was a little worried before starting this project about whether everything would work out or whether my money would go to waste. However, I think it was a good decision in the end.
There's a certain satisfaction in running your own server and having more control over your data and the services you use. This project has also given me an opportunity to learn more about Linux, Docker, networking, and managing multiple services.
I haven't fully utilized this setup yet, and there is still a lot I want to do. But I think that's part of what makes a project like this interesting. I can keep improving it, experiment with new ideas, and learn along the way.
