What a Nine-Year-Old Gaming PC Can Actually Do
I had a desktop I built in 2016 that was no longer useful for gaming but was otherwise a perfectly capable machine. Rather than letting it collect dust or contribute to e-waste, I repurposed it into a personal cloud and application server — my own centralized hub for file storage, photo backups, password management, automation, and a handful of self-hosted services I’d otherwise be paying monthly fees for.
The honest motivation was two things at once: subscription fatigue and annoyance at not owning my own data. Every password manager, photo backup, cloud storage, and productivity tool accumulates. The costs add up, and more importantly, you don’t actually control any of it. I wanted a single environment I could depend on and understand end-to-end, running on hardware I already owned.
What the Server Actually Runs
The server handles file sharing via SMB network shares across all my personal devices. Remote access works from anywhere without opening any ports to the public internet — more on that below.
The application stack is what makes it genuinely useful day-to-day:
- Immich for photo backups, replacing Google Photos
- Nextcloud for file sync and document editing
- Vaultwarden for password management, replacing a commercial password manager
- n8n for workflow automation and business logic
- Milvus for vector database workloads
- Minio for S3-compatible object storage
- Umami for privacy-respecting web analytics
- Uptime Kuma for service monitoring
All of these run in Docker containers, managed through Portainer.
Why These Choices
I chose TrueNAS Scale over other options because of its Debian Linux foundation and native ZFS support. ZFS isn’t just a filesystem — it’s a data integrity system. It detects and corrects silent data corruption, supports scheduled scrubs, and makes snapshot-based backups straightforward. For a personal archive of photos and important files, bit-rot protection matters more than raw performance. TrueNAS also handles containers natively, so it serves as both the storage OS and the application host without needing a separate machine.
Docker with Portainer rather than bare-metal installs was the obvious call. Running services bare-metal on a single OS creates dependency conflicts and makes updates risky. Containers isolate everything cleanly. Portainer gives me a visual interface for managing multi-container deployments without having to remember every docker-compose incantation.
The networking decision was the most interesting one. Tailscale, built on WireGuard, creates a private encrypted mesh network between my authenticated devices. The server joins that network and becomes reachable from anywhere — my laptop, my phone, a friend’s machine I’ve authorized — without exposing a single port to the public internet. No SSH accessible from the outside. No web services on public IPs. To anyone scanning the internet, the server looks like it isn’t there.
Securing Remote Access Without the Usual Trade-offs
The traditional approach to remote server access is uncomfortable: expose SSH on port 22 (or a non-standard port), manage IP whitelists, and hope your firewall rules are correct. All of that breaks down when you’re traveling or working from a new location. Dynamic IP addresses mean whitelists become a maintenance problem.
Tailscale sidesteps this entirely. By configuring the SSH daemon to bind only to the private Tailscale IP address and using UFW to deny all inbound SSH from the public interface, the server becomes administratively invisible to the public internet. Access is cryptographically verified through Tailscale’s identity system. I can SSH into the server from anywhere, as long as my device is on the tailnet — and adding a new device takes about two minutes.
This shifted my mental model around security. “How do I secure this exposed port?” is the wrong question. “How do I make this port invisible?” is better.
What I Learned Running This
The nine-year-old hardware runs containers without strain. Modern computing hardware has vastly outpaced standard workload requirements — what a machine needed to do for gaming in 2016 is more than sufficient for container orchestration and data serving in 2025. The upgrade that actually mattered was adding storage capacity, not compute.
Taking ownership of tools like Vaultwarden and Nextcloud also changes how you relate to the software. You start thinking about uptime, backup strategies, update procedures. It breeds a deeper understanding of what infrastructure actually involves — not as an abstraction, but as something you’re responsible for.
Where This Goes
The most important gap in the current setup is off-site backup. ZFS provides excellent local redundancy against hardware failure and bit-rot, but the server itself is a single point of failure for a power outage, fire, or theft. Implementing an encrypted, automated sync of mission-critical datasets to a remote location is the right next step for real disaster recovery.
After that, network segmentation. Running all workloads on the same flat network is convenient but not ideal from a security standpoint. Segmenting via VLANs to isolate the externally-facing application containers from the most sensitive databases and backup arrays would add a meaningful layer of internal security — especially as the number of hosted services grows.
