New Ideas for My Homelab in 2025
New Year, New Homelab! As we step into 2025, I’ve been reflecting on how to best host my services in my homelab. This year, my goal is to focus on efficiency and high availability. After much thought, I believe it's time to streamline my setup and make sure my services are always available, even during updates or outages.
Embracing High Availability
I’m declaring 2025 the year of high availability. To achieve this, I plan to downsize my homelab servers to more compact, efficient units—something like the Miniforum MS-01. This machine supports 10Gb Ethernet and comes with a powerful CPU that’s perfect for my needs.
After watching the recent LTT video, I realized that I could also add a low-profile RTX 4000E card into the MS-01, which would open up possibilities for transcoding and AI tasks. This will give me the flexibility I need while maintaining the performance I expect.
The beauty of using multiple MS-01 devices is that I can create a more fault-tolerant setup. By having several of these machines running in parallel, I can achieve high availability for the critical services in my homelab. If one device goes down, the others will seamlessly take over, ensuring minimal disruption.
Eventually, I’d like to experiment with Kubernetes or Docker Swarm. With this kind of orchestration, I could easily bring nodes offline for maintenance, updates, or when troubleshooting failures—all while keeping services up and running without interruption.
Rethinking Service Configuration
As part of rethinking my homelab, I’m also considering a shift in how my services are deployed. One idea I’m exploring is running all my services through Tailscale within Docker containers. Since most of my services are already containerized, this transition should be relatively smooth.
With Tailscale, I could set up secure, private connections between my devices, simplifying the management of access control. Once I have Tailscale in place, it will be much easier to share specific services with my family members, giving them access only to the ones they need, and keeping everything else secure and isolated.
While I’m still figuring out the finer details of this setup, I’m also considering a move to LXC containers on Proxmox. I’ve heard great things about the backup and restore capabilities of LXC, especially when it comes to recovering from corrupted systems. This could be a more efficient solution for managing my containers, especially if I need to roll back or restore a service quickly.
Expanding My Network
In 2025, I’m considering moving all services to the 10.1.50.0/24 network to allow for future expansion and avoid being limited to VLAN 10 or 20 for devices.
Why Do I Do This?
Because it’s fun. I love building and maintaining servers and making sure I’m using the latest technology where it makes sense.
In 2024, I migrated my NAS from Synology to TrueNAS with almost 4× the raw storage. That lets me balance performance and capacity while expanding the array over time. I learned a lot the hard way: buy enterprise drives, avoid single points of failure, be careful with external JBODs, and more. I’ve invested a lot in redoing my NAS, and I hope it will serve as the main storage for years, with incremental upgrades as needed.
In 2025, I plan to make services highly available and more secure by gating access through Tailscale. This moves my network toward a Zero Trust model, granting VPN access only to those who need it (excluding the NAS).
Testing Complete
While writing this post, I tested using a Tailscale sidecar container to connect other containers with network_mode: service: ts-container in Docker Compose. I needed to add the following to ACLs:
"tagOwners": {
"tag:appname": [],
},
This allows tagging the service, making it easier to organize and scope tokens to specific tags.
"acls": [
{"action": "accept", "src": ["autogroup:shared"], "dst": ["*:443"]},
],
Adding this ACL in Access Control limits incoming connections to port 443 only. It’s a simple way to enforce HTTPS, with certificates managed by Tailscale via MagicDNS and HTTPS.
Testing with a second Tailscale account, I verified access using the full domain, like sterlingpdf.tailnetname.ts.net. It would be nice if clicking the service opened https://sterlingpdf.tailnetname.ts.net directly when sharing with family, in case the default link doesn’t work.
End Game
I should create LXCs to manage data better and isolate traffic per service. Using Tailscale for connectivity gives me control and feels like a good path for the transition.