I got started with homelabbing when I was pretty young, using an old iMac and running Puppy Linux. That early curiosity grew into a deeper interest as I built a basic NAS using a Supermicro Intel Atom (X7) board running FreeBSD. At some point, a friend and I built a Proxmox server, and I was playing with BeagleBone boards for side projects. Around the same time, I was forcing myself to use Arch Linux on a laptop, while working professionally in a Windows Server environment. That mix of self-learning and hands-on exposure to different platforms helped me get comfortable picking up new technologies quickly.
Current Setup
These days, my home lab lives across two small 19-inch racks. The main rack, mounted high on the wall, has our core networking gear: a Ubiquiti UDM-PRO and an Enterprise 24-port PoE switch. That powers our home’s Wi-Fi (upgraded recently to Wi-Fi 6E) and a handful of PoE security cameras. There’s also a SFP+ fiber line that runs across the office to a UDM Enterprise 8-port switch in a second 12U rack.
That rack also holds an UNVR. I added that after running into memory issues with the UDM-PRO doing too much—it was right at the suggested limits, and it showed. The star of the setup, though, is our Unraid server—a project I built with my brother and a good friend:
Motherboard: Supermicro H11SSL-NC
Processor: AMD EPYC 7281 16-Core
Memory: 64GB ECC RAM
GPU: NVIDIA RTX A2000
Storage Configuration:
Main Storage: 8x 16TB SATA HDDs in an Unraid array with dual parity
SSD Pools: 2x 1TB consumer SSDs in ZFS mirrors, split across three pools for VMs, Docker containers, and caching
It runs everything from media services and game servers to tools like Pi-hole, budget trackers, Nextcloud, and more recently, Ollama models. It’s been fun pushing into AI workloads, but also kind of the tipping point for this system.
Identified Limitations
Once I started running LLMs through Ollama, I noticed performance hitting a ceiling—IOPS, memory, and CPU were all getting pushed. I’ve also been using Docker Compose more heavily, and while Unraid’s UI was great when I was starting out, now it feels like it’s getting in the way more than helping.
To be honest, I also went through a phase where tech as a hobby just wasn’t doing it for me anymore. But over the last 6–8 months, that spark came back—mostly thanks to AI tools helping me break through a few roadblocks. That motivation has been key to where I’m going next.
Future Plans and Learning Opportunities
I stumbled onto the idea of a mini-rack build while browsing setups—and the concept really clicked. The plan is to build out a new 10-inch rack and move most of the workloads over to that, while the Unraid server continues as a NAS and VM host.
New Mini-Rack Infrastructure
Networking Backbone
10Gbps uplink to the main rack via an 8-port Ubiquiti switch
2.5Gbps ports for internal communication across the new stack
Storage & Kubernetes Traffic
A MikroTik 8-port SFP+ switch for 10Gbps communication between storage and k8s nodes
Control Plane
3x Raspberry Pi 5 units (8GB each), active cooling, M.2 SATA hats & 1x 16GB as a jump / admin box.
Connected over a Unifi Lite 1Gbps switch
Compute Nodes
Two Minisforum MS01 boxes will act as the primary nodes:
Intel Core i9-12900H
96GB RAM (2x48GB Crucial)
1TB NVMe (Inland) for the OS
2x 2TB SK Hynix NVMe drives each for Ceph storage
The goal is to run Kubernetes on bare metal, using Ceph for distributed storage. We’re still doing hardware testing and burn-in now, but once that’s done, I’ll start migrating workloads and services over. Eventually, I’d love to add a small SSD-only NAS to complement the setup—but we’ll see what budget and time allow.
Learning Goals and Opportunities
This project is giving me a real-world sandbox to explore:
Running a high-availability k8s control plane on ARM-based nodes
Building and maintaining Ceph storage in a home environment
Learn about container orchestration.
Using GitOps to manage and deploy infrastructure and applications
The new setup is a chance to go deeper into container orchestration and storage architectures, while still scratching that tinkering itch. It’s been a lot of fun diving back in with a more intentional approach—and I’m excited to see where it leads.
Pangolin is an exciting new tool designed to simplify remote access to self-hosted resources, bypass CGNAT issues, and seamlessly integrate with security tools such as Crowdsec. With its recent 1.0 release, Pangolin continues to evolve, incorporating powerful new features.
Why Switch to a VM-Based Setup?
In my experience, the optimal approach to using Pangolin on Unraid is to bypass the official Unraid installation guide provided by Fossorial and instead deploy Pangolin within an isolated virtual machine (VM). This method simplifies the integration with Crowdsec and leverages Docker Compose for easier management.
Steps to My Transition
Network Configuration
Created a dedicated VLAN specifically for Pangolin.
Configured firewall rules to allow outbound traffic only, preventing communication with other internal networks.
Enabled administrative access from trusted local networks.
Unraid Configuration
Established a new network interface linked directly to the VLAN.
Virtual Machine Setup
VM Specs: 4 CPU cores, 4 GB RAM (additional resources allocated for Crowdsec).
Set networking to default settings within the VM for simplicity.
Mounted shared host files via VirtioFS at /pangolin to enable easy backups of configurations and logs.
Transitioning to a VM allowed me to simplify my setup by removing several Docker containers previously managed in Unraid:
Pangolin
Gerbil
Traefik
Crowdsec
Newt Configuration
Adjusted the networking setup within Unraid Community Applications.
Added two custom networks, and left the built in unraid networking field blank.:
New VLAN (br3), assigned a manual IP due to networking conflicts.
Docker network (fossorial) for containers accessed through Pangolin and Newt.
Generated Newt ID and secret, configuring these as container variables from the new Panolin install.
Crowdsec Integration
The VM setup significantly simplified Crowdsec integration, particularly through tools like Crowdsec Manager, enabling straightforward management of enrollments, whitelists, and custom security scenarios including Cloudflare Turnstile.
Enhanced Security with Cloudflare Tunnels
To further enhance security, I’m utilizing Cloudflare Tunnels with their WAF. The tunnel is hosted via Unraid Community Applications within the dedicated VLAN. The traffic flows as follows:
For accurate IP address detection through Cloudflare, I’m using the Traefik Real-IP Plugin.
Future Plans
My next step is integrating Crowdsec directly with Cloudflare’s WAF to shift blocking responsibilities away from Traefik. Previously attempted IPS and geoblocking solutions with UDM Pro proved resource-intensive, reaffirming my preference for Cloudflare’s robust security.
Here’s a tutorial for 1889 on the 18xx.games platform: 18xx Games Tutorial. It walks you through turns of a three-player game, illustrating typical gameplay elements.
For 18xx games, most are derived from 1830 with modifications (sometimes significant ones that the community refers to as “McGuffins”). Key variations include the maps, available companies, tile availability, and train rules. Additionally, auction methods for companies, stock market mechanisms, and company-specific rules often differ, leading to uniquely challenging games.
Although 1830 is one of the earliest 18xx games, it followed the lesser-known 1829. 1830 is the foundation for most other 18xx games.
The more introductory games like 1889, 18Chesapeake, and 18MS, which are based on financial strategies from 1830. These games focus on timing investments and manipulating stock prices. The most significant game in this financial category is 1817, which can last over 12 hours due to its complex stock market dynamics.
Another category within the 18xx series focuses on operational games, such as 1846, designed by the creator of Race for the Galaxy. 1846 emphasizes efficient company operation, route competition, and critical timing of train upgrades, making it an accessible entry point for those new to operational strategies within the 18xx series. 1822, another significant game in this genre, is known for its lengthy gameplay and intricate management of private companies, but it may not be as suited for beginners due to its complexity.
Gameplay typically alternates between Stock Rounds and Operating Rounds, which may vary in number as the game progresses. During Stock Rounds, players buy and sell shares, affecting company valuations. In Operating Rounds, companies operate trains, manage routes, handle dividends, and invest in new trains. A crucial tip for beginners is to prioritize train purchases, which can accelerate game progression and disrupt opponents’ strategies.
Trains, which have finite lifespans, need careful management to prevent obsolescence and ensure operational efficiency. Newer trains make older models obsolete (“rusting”), forcing players to continually adapt their strategies.
Companies are usually divided into public and private. Private companies, often starting smaller, can later be integrated into public ones, providing strategic financial benefits. Company funds stem solely from share purchases, and operational decisions during rounds can significantly impact overall success.
Tracks are categorized into three types: Yellow, Green, and Brown, representing different stages of development. Starting with Yellow, players can upgrade to Green and then Brown, each providing different strategic options. Tile availability is typically limited, encouraging strategic placement to potentially hinder opponents’ expansion.
During Operating Rounds, per train you can run a route where track cannot be reused by your company for multiple routes. You can’t backtrack normally. The number of stations a train visits, typically its numeric value like a “2 train” or a “4 train,” is crucial as it dictates the potential revenue from that route. Each station adds a set value to the route’s total income, influencing strategic decisions about train operations and route planning.
Here is an example board from a completed 1889 game:
Example: If you had a station in Nahari, and two “2” trains, you could run two routes. One from Muroto to Nahari for 40 dollars, and one from Nangoku to Nanari for 30. A total of 70 for the operating round.
If you had a 3 train, you could run between Muroto to Nanori to Nangoku for 50, or if you additionally had a station in Kouchi and a 3 train, you could run to Kouichi to Nangoku to Nanari for 90.
You may not reuse track during a route, but you may visit a station with multiple trains as long as you do not resuse track.
Today I tried to install TigerVNC Server on Ubuntu 16.04, and was surprised to find that Ubuntu still uses TightVNC in their main repos. Additionally, there are no PPAs for TigerVNC and Ubuntu 16.04 Xenial Xerus yet.
Installing it is simple:
+Download the latest binary from TigerVNC. At the time of writing, version 1.7.0 for Ubuntu is located here for 64bit and here for x86.
Latest release information can be found on the (TigerVNC github page)[https://github.com/TigerVNC/tigervnc/releases].
You will be prompted for a few questions the first time you start it up, but that it is it. Your VNC Server is up and running on port 5901 by default. You can connect to it using the Tiger VNC viewer on another computer by pointing it to the IP:5901.
There are a lot of options for TigerVNC server, but one of my favorite things about TigerVNC is that the connections are encrypted by default. However, I recommend only connecting to VNC servers over VPNs or SSH tunnels just to be sure.
