ilapaj Library
Articles 日本語
15 min read (2,995 words)

I Started Running a Home Server

This is an English translation of the original Japanese article, translated with the help of AI.
Table of Contents

I’m sinking into the self-hosted rabbit hole.

Falling into the Self-Hosted Rabbit Hole (Setup Notes for FreshRSS, RSSHub, Memos, Uptime Kuma, Netdata, and Nginx Proxy Manager)

As I wrote in the article above, hosting on a VM in the cloud kind of defeats the whole “don’t let companies hold my data” point, so I decided to set up a server at home and build a homelab.

It was my first time doing any of this and I had no idea what I was doing, so I worked through it while consulting Professor Gemini (the AI). This article was written by Professor Gemini, based on that chat history.


Introduction: The Big Picture of the Homelab Built in This Article#

This article is the record of an adventure in which one old PC, left sleeping in a closet, was reborn as a modern home server (homelab) built on Proxmox and Docker.

By the time you finish reading, you’ll know how to build a flexible and powerful server environment with the following layered structure.

The Finished Design: A Multi-Layered Homelab#

The idea is to build a virtualization platform on top of physical hardware, create purpose-specific workshops (VMs) inside it, and run a universal machine tool (Docker) inside those.

[ Your PC (Mac/Windows) ]
|
(Tailscale's magic tunnel)
|
+-------------------------------------------------+
| [Physical layer] Salvaged PC |
| + CPU: Core i3-7100 |
| + Memory: 8GB |
| + Storage: NVMe SSD (for OS) + HDD (for data) |
| |
| +-------------------------------------------+ |
| | [Virtualization layer] Proxmox VE | |
| | | |
| | +---------------------------------------+ |
| | | [VM layer] Ubuntu Server 24.04 (`lumine`)|
| | | | |
| | | +---------------------------------+ | |
| | | | [Container layer] Docker | | |
| | | | + Netdata (monitoring tool) | | |
| | | | + Jellyfin (to be added later) | | |
| | | | + ... | | |
| | | +---------------------------------+ | |
| | +---------------------------------------+ |
| +-------------------------------------------+ |
+-------------------------------------------------+

Setup#

Hardware#

  • Mothership PC: A desktop PC salvaged from my university lab
    • CPU: Intel(R) Core(TM) i3-7100 @ 3.90GHz
    • Memory: 8GB
    • Motherboard: ASRock B250M Pro4
    • Existing storage: 1TB HDD (TOSHIBA DT01ACA100)
  • A new soul (added parts):
    • System drive: Apacer AS2280P4 (512GB M.2 NVMe SSD), 5,000 yen (about $33)
    • Excavated find: A mystery 256GB SATA SSD

Software#

[Prologue] I Hereby Establish a “Homelab”#

I’m sinking into the self-hosted rabbit hole.

As I described in the article above, I built a self-hosting environment on a cloud VM, but several problems surfaced. Using a VPS means that, in the end, your data sits under the physical control of the hosting company. How could I achieve my original goal of “not letting companies hold my data” in a purer form?

The cloud has advantages like stable uptime and fixed IPs. But if you want true data sovereignty, physical ownership is essential. On top of that, capacity and performance can’t be ignored. Handling large media files and real-time video transcoding in the cloud would cost an unrealistic amount.

So I changed course. I would put a server in my home and build a “homelab”.

Luckily, I already had a machine to serve as the project’s mothership. When the lab I used to belong to was shut down, a desktop PC had been put out as junk, and I salvaged it from the trash area.

Apparently it’s a no-no to do this with expensive PCs since they have asset tags, but this one didn’t, so it should be fine…

It had been sleeping in my closet for several years, but its time to show its true worth had finally come.

This article is a work log of the whole process of this “picked-up” PC being reborn as a modern home server.

[Chapter 1] Dawn: A Dialogue with the Hardware#

I powered on the salvaged PC and started by assessing the current state. Luckily the OS (Ubuntu 17.10) booted, so I checked the detailed specs from the system information.

  • CPU: Intel(R) Core(TM) i3-7100 @ 3.90GHz
    • 2 cores, 4 threads. The core count is shaky for server use, but the high single-core performance at 3.90GHz should help the responsiveness of many web services.
  • GPU: Intel HD Graphics 630 (Kaby Lake GT2)
    • Notably, it supports Intel Quick Sync Video (QSV), which assists with hardware video encoding/decoding. For building a media server like Jellyfin, this is a powerful weapon that can drastically cut CPU load.
    • Not sure if that’s actually true.

  • Memory: 8GB (7.5GiB)
    • Enough capacity to run several Docker containers. I’m also keeping future expansion in mind.
  • Storage: 1TB HDD (TOSHIBA DT01ACA100)
    • A 7200 RPM SATA HDD. Great as a vault for large amounts of data, but its random access performance is fatally lacking for running an OS and applications.
  • Motherboard: ASRock B250M Pro4
    • An important part that determines expandability. I need to check the specs on the web.
  • OS: Ubuntu 17.10
    • Support ended completely in 2018, so security-wise it’s out of the question. A clean install of the OS is a must.

From this analysis, I concluded that “this machine has high potential as a media server, but storage is a serious bottleneck.”

The next move was clear: add a boot SSD to run the OS and applications. I checked the motherboard (ASRock B250M Pro4) specs on the official website and found something very important. This motherboard has a PCIe Gen3 x4 “Ultra M.2” slot, far faster than a regular 2.5-inch SATA SSD (max 6Gb/s). It supports NVMe SSDs with transfer speeds of up to 32Gb/s, and it’s the key to bringing out this machine’s full potential.

The plan was set.

“Use a PCIe Gen3 M.2 NVMe SSD as the system drive, and use the existing 1TB HDD as the data drive.”

With this configuration, the OS and Docker run at blazing speed, and large data like videos can be stored on the HDD without a second thought.

I headed straight to Akihabara (Tokyo’s electronics district), weighed market prices against performance, and bought a 512GB M.2 NVMe SSD (PCIe Gen3, size 2280). This would be the machine’s new soul.

After getting home, I seated the NVMe SSD in the motherboard’s “Ultra M.2” slot and fixed it with a screw. The physical preparation was now complete.

The NVMe SSD I bought. Apacer SSD 512GB M.2 PCIe Gen3 x 4 NVMe.

I’ve loved Tsukumo-tan ever since I bought my first-ever BTO (build-to-order) PC, so I always buy PC parts at Tsukumo Electric (a Japanese PC parts shop; Tsukumo-tan is its mascot). The thing next to it is garlic powder I bought at the supermarket while I was at it. I used it to make spaghetti as a late-night snack right away. It was delicious.

Come to think of it, I hadn’t seen Tsukumo-tan around lately, and it turns out her contract has ended. So sad.

Addendum#

The SSD didn’t come with screws, so I managed to dig up ones with the right diameter from a container full of junk left over from when I was into electronics projects.

While searching for screws, I also found a 256GB SATA SSD with a sticky note on it that said “DEAD”. It was probably the drive that originally ran as the C drive in my current PC, and I’d pulled it because it had failed (or so I thought). But I tried connecting it just to see, and it worked fine, so I decided to remove the optical drive and install this in its place.

If I’d had one more SATA cable, I wouldn’t have needed to remove the optical drive…

Here it is, recognized without a hitch.

Another Addendum#

The HDD had my seminar materials from my student days and the audio data for the listening exercises from a TOEFL iBT prep book. Nostalgic.

I should have pushed the projects and code from back then to GitHub, so there shouldn’t be any other important data.

[Chapter 2] Genesis: Building a Virtual World with Proxmox#

The physical preparation was done. Next came the main event: choosing and installing the OS that would be the server’s brain. I could have simply installed Ubuntu Server directly, but to get the most out of the homelab’s possibilities, I decided to make a more ambitious choice: introducing the virtualization platform “Proxmox VE”.

The Philosophy of OS Selection: Why Proxmox?#

With Proxmox VE, the OS itself acts as a hypervisor that manages virtual machines (VMs) and containers (LXC). Adopting it means not just setting up a single server, but getting your own personal cloud environment where you can freely build and destroy multiple independent servers inside it.

This approach has immeasurable benefits.

  • Flexibility: You can separate VMs per service and completely cut off environment dependencies.
  • Safety: You can try experimental apps in an isolated VM without polluting the host environment.
  • Manageability: Snapshots and backups of whole VMs are easy, and the peace of mind of “I can restore it right away even if I break it” makes bold experiments possible.

The plan was decided. Install Proxmox VE on the physical machine, and build an Ubuntu Server VM on top of it to serve as the main workshop.

Installing Proxmox VE#

I downloaded the latest ISO image from the Proxmox VE official site and created a USB install medium with balenaEtcher. I booted the PC from the USB stick and started the graphical installer.

The installation process was surprisingly smooth.

  • Target disk: Correctly selected the newly purchased 512GB NVMe SSD.
  • Network settings: To match my home network, I set a static IP address (192.168.3.200/24), gateway (192.168.3.1), and DNS server (1.1.1.1).
  • Hostname: Set to pve1.local.

After a few minutes of copying files, the Proxmox VE installation was complete. After the reboot, a pve1 login: prompt appeared on a black screen. This was the moment the server’s foundation finally let out its first cry.

Building the Workshop: Setting Up the Ubuntu Server VM#

From the browser on another PC, I accessed Proxmox’s web management interface (https://192.168.3.200:8006). From here, I would create the Ubuntu Server VM that would serve as the main Docker host.

  • ISO image: From the Ubuntu official site, I downloaded the ISO of the latest long-term support release, Ubuntu Server 24.04 LTS. Using a Proxmox feature, I gave it the URL and had it saved directly onto the NVMe SSD.
  • VM resource allocation:
    • CPU: 2 cores
    • Memory: 4096MB (4GB)
    • Disk: 64GB
    • I decided to allocate about half of the physical machine’s resources to this first VM.

I created the VM and started the Ubuntu Server installation from the console screen. Here too I made one important choice. For the installation type, instead of the standard Ubuntu Server, I chose Ubuntu Server (minimized). This decision rests on the server administration principle of “minimizing the attack surface” and the philosophy of “adding only what you need, by your own hand.”

I went through the network settings and user creation, taking care to check “Install OpenSSH server”, and the Ubuntu installation finished without incident. With that, inside the building called Proxmox, a workshop named ubuntu-docker was complete.

Final Touches#

In the VM options, I enabled “Start at boot”. This ensures the VM starts up automatically even when the server itself reboots, giving it the autonomy of a true server.

I logged into the ubuntu-docker VM from an SSH client, updated the system to the latest state with apt update && apt upgrade, and finally used the handy script from the Docker official site to install Docker Engine and Docker Compose.

Once docker run hello-world succeeded, all the foundations were in place. A virtualization platform on the physical machine, and a container runtime environment running on top of it. A sturdy, flexible, multi-layered homelab foundation was now complete.

[Chapter 3] Fierce Battle: Legendary Troubleshooting#

See the article below. This one I wrote myself, not Professor Gemini.

A problem came up where the machine wouldn’t boot because of a dead CMOS battery, and I wrestled with it for 5 hours.

If Your PC Won’t Boot, Replacing the CR2032 (CMOS) Battery Might Fix It

[Chapter 4] Applied: Building a Network That Connects the World#

Proxmox the building, Ubuntu the workshop, and Docker the universal machine tool. With all the foundations in place, it was finally time to run applications and breathe life into this homelab.

Naming My Partner: lumine#

I decided to give this new base of creation a fitting name. As my partner for the adventures ahead, I named the host lumine. This name, borrowed from the Traveler in Genshin Impact, is the very image of this project: traveling through another world (self-hosted) and seeking lost technology (knowledge). I unified the server’s own name and its device name on Tailscale as lumine, and set things up so I can reach it with ssh lumine.

Side Note#

On naming hosts, from what I looked up, there were plenty of sensible opinions along the lines of “don’t make names funny, make them describe the function.” But this is a hobby, and I want to enjoy using it. Taking my cue from the lab’s servers, which were named after researchers of the past, I decided to give mine abstract names too.

When I reported to Professor Gemini that the boot trouble was solved, it described it as having “risen like a phoenix.” So, following the Genshin Impact Natlan storyline I’d played recently, I went with lumine as the hostname. And the idea that you can do all sorts of things once you put Docker containers on it might suit Lumine, who can wield multiple elements… maybe.

Thoughts on Genshin Impact’s Natlan Archon Quest (Spoilers)

It would be a lot of fun to keep naming future additions after Genshin Impact characters. Like, lumine itself doesn’t open a single port, but a paimon VM makes it reachable through a reverse proxy, and nahida is in charge of monitoring all the servers.

If the roles had been clearly defined in advance, there’d be no benefit at all in giving weird names. But at the PoC stage, I think it’s better to give names that spark the imagination: you avoid a mismatch between the name and the function, and you can imagine things from the name and run all sorts of experiments. And this goes not just for hobbies but for work too.

Self-Monitoring with Netdata#

The first thing I tackled was installing a monitoring tool to keep tabs on the server’s own state. I chose Netdata, well regarded for its real-time updates and beautiful dashboard. Using Docker Compose, I just wrote a few lines of docker-compose.yml, and the deployment was done with surprising ease.

version: '3'
services:
netdata:
image: netdata/netdata
container_name: netdata
hostname: lumine # Specify the hostname
ports:
- 19999:19999
# (permission settings etc. follow below)

At this point, though, the Netdata dashboard could only be viewed from inside the server. To make this homelab truly usable “from anywhere,” securing a safe remote access route was essential.

A Private Tunnel with Tailscale#

That’s where Tailscale comes in. It’s a magical VPN service that connects your devices into a single encrypted private network (an overlay network) without requiring any complicated setup.

Kind of like the good old Hamachi?

I installed Tailscale on both lumine itself (the Ubuntu VM) and my everyday MacBook. Just by running the official install script and authenticating on the web, a virtual LAN that transcends physical location was built. lumine was assigned a special IP address starting with 100.x.x.x, and just by typing http://100.x.x.x:19999 into the MacBook’s browser, I could securely access the Netdata dashboard.

Now I had the basic administrator environment: wherever I am, I can monitor lumine’s state in real time.

[Epilogue] The Real Adventure Begins Now#

After many twists and turns, the ideal homelab has finally taken shape.

  • Physical layer: The salvaged PC received a new heart transplant in the form of an NVMe SSD.
  • Virtualization layer: Proxmox VE provides a virtualization platform full of infinite possibilities.
  • OS layer: Lightweight and secure Ubuntu Server runs stably as the Docker host.
  • Network layer: Tailscale delivers safe and convenient remote access.

The foundation for a hybrid setup, where the public-facing services running on the VPS and the private services running on lumine at home work together, has just been completed.

But this isn’t the end. Rather, it’s where the real beginning starts. Installing Jellyfin to unleash lumine’s true power (QSV). Building Nextcloud to make use of the large storage. And encounters with new self-hosted apps I haven’t even met yet await me.

A homelab is not just building a server. It is an endless adventure, and the ultimate intellectual hobby. I sincerely hope this article becomes the spark that breathes new life into a PC sleeping in someone’s closet.

All the illustrations in this article were made with nano-banana. This one in particular has a sinister vibe that I love. What the heck is “ブイラトスッケケ” (Buiratosukkeke)?

More articles

All articles →
ilapaj
ilapaj

Notes on games, radio and technology, translated from the Japanese blog.

封面
Sample Song
Sample Artist
封面
Sample Song
Sample Artist
0:00 / 0:00