• A step-by-step install guide for software such as TrueNAS
• Or a massive rack-mounted setup with more drives than most small businesses will ever need

Neither of those was what I was looking for.

I didn’t want a homelab, I didn’t want a science project, And I definitely didn’t want something that sounded like a server room sitting five feet from my desk.

I wanted something simple:

A reliable, quiet NAS that fits into a real office and just does its job.

This is how I approached that problem—and why I landed on TrueNAS.

The Constraints (This Is Where It Starts)

Before looking at hardware or software, I had to be honest about the constraints.

This wasn’t going into a basement or a dedicated rack closet; it was going into a small office where I actually work every day.

That meant:

• Noise matters — constant fan and/or hard disk noise gets old fast
• Size matters — I don’t have space for a full rack server
• Power usage matters — this runs 24/7
• Reliability matters — this is storing real work, not media hoarding
• Cost matters — but not at the expense of stability

And maybe most importantly:

I didn’t need “infinite scalability.” I needed “appropriate capacity.”

That framing alone rules out a lot of overbuilt solutions.

Why Not Just Buy a Synology?

I seriously considered it.

Synology (and others) are great for:

• Plug-and-play setups
• Low effort
• Clean UI

But I kept coming back to a few concerns:

• You’re locked into their ecosystem
• Hardware is often underpowered for the price
• You don’t really control the underlying system
• ZFS (which I wanted) isn’t part of the story

For some use cases, that tradeoff is fine. For mine, I wanted something that felt a little closer to the metal, without becoming a full-time job to manage.

Why Not Reuse Old Hardware?

This is the classic “free NAS” trap.

Take an old desktop, throw some drives in it, install something, and call it a day.

The problem is:

• It’s usually louder
• It’s often less power efficient
• It tends to become less reliable over time

It works—until it doesn’t. I wanted something intentionally built for the role.

Hardware: Right-Sized, Not Overbuilt

I ended up building around an Intel N5105-based motherboard in a compact NAS case.

That decision wasn’t about chasing performance—it was about practicality.

A big factor was:

I already had DDR4 SO-DIMMs on hand

That immediately lowered the cost of the build and made the N5105 platform a very natural fit. It’s easy to overlook things like existing parts, but they can (and should) influence your decisions.

Beyond that, the platform checked the boxes I cared about:

• Low power draw
• Quiet operation (no need for aggressive cooling)
• Enough performance for storage and light services
• Compact, purpose-built NAS boards available

For storage, I went with:

3 × WD Red Plus 6TB drives Configured as RAIDZ1

Why 3 drives?

Because it hit the balance I was looking for:

• Redundancy
• Reasonable usable capacity
• Lower cost and less noise than a larger array

Could I have gone bigger? Sure. But again, the goal wasn’t to build the biggest NAS possible—it was to build the right one.

The Case for Quiet

The case matters more than most people think.

I went with a Jonsbo N1, which is:

• Compact
• Clean looking
• Designed for NAS builds
• Capable of good airflow without excessive fan noise

Combined with:

• Fewer drives
• Efficient CPU
• No unnecessary components

…the result is something that fades into the background.

That was the goal.

Why TrueNAS

Once hardware was settled, the OS decision became much easier.

I considered:

• Unraid
• Plain Linux + ZFS
• Even going back to something simpler

But TrueNAS hit the balance I wanted:

1. ZFS Without Compromise

ZFS was a requirement:

• Snapshots
• Data integrity
• Long-term reliability

TrueNAS treats ZFS as a first-class citizen.

2. A Real UI (Without Losing Control)

I didn’t want to manage everything via CLI.

But I also didn’t want a locked-down appliance.

TrueNAS sits in a good middle ground:

• Web UI for 90% of tasks
• CLI available when needed

3. Designed for This Exact Use Case

TrueNAS isn’t trying to be everything.

It’s very clearly designed to:

Store data reliably.

That focus shows up in:

• Dataset management
• Snapshots
• Replication
• Backup workflows

Setup: What Actually Mattered

There are plenty of guides on installing TrueNAS, so I won’t repeat that.

What did matter:

Network Gotchas

My onboard NICs didn’t behave as expected during install.

This is one of those moments where:

Having a simple USB Ethernet adapter saved a lot of time.

Once installed, everything worked—but it’s a good reminder that:

• Hardware compatibility still matters
• “Supported” doesn’t always mean “smooth”

Pool Design

I kept things simple:

• boot-pool (system)
• core-pool (main RAIDZ1 storage)

There’s a temptation to over-engineer this early. I’d recommend resisting that. Start simple. Expand later.

Dataset Structure

Instead of dumping everything into one dataset, I split by purpose:

• Backups (Proxmox)
• General storage
• Future expansion

This gives flexibility later without overcomplicating the initial setup.

How It Fits Into My Stack

This NAS isn’t standalone.

It’s part of a broader setup:

• Proxmox running VMs and containers
• Backups flowing into TrueNAS
• Future plans for snapshots and replication

The goal is:

Compute happens on Proxmox Storage lives on TrueNAS

Keeping those roles separate has already proven to be the right call.

What I’d Do Differently

A few small things:

• I’d plan static IP assignments earlier
• You don’t need a huge boot drive; I settled on 32GB and it’s been plenty
• I’d document drive bay → serial mappings sooner

Nothing major—but these are the kinds of details that matter over time.

Final Thoughts

There are a lot of ways to build a NAS.

Most of them fall into one of two categories:

• Overbuilt
• Or underthought

I was aiming for something in the middle.

• Not flashy.
• Not massive.
• Not complicated.

Just:

Reliable, quiet, and appropriate for the job.

And for that, TrueNAS turned out to be the right foundation.

If you’re building something similar, my advice is simple:

• Start with your constraints.
• Be honest about what you actually need.
• And resist the urge to build for a future that may never come.

That alone will get you 90% of the way there.

Once the stakes changed, so did the approach. Something you’re willing to let break overnight is very different from something you actually need to work. That meant building with intention: defined structure, real recovery paths, and a level of trust you don’t usually demand from a weekend project.

This isn’t about building the flashiest setup. It’s about applying production thinking at personal scale, without pretending I have an enterprise budget behind it.

The Goal: Treat It Like Production (Without the Budget)

I don’t want a toy.

I want something that:

• Survives mistakes
• Recovers quickly
• Mirrors real-world architecture decisions
• Doesn’t require babysitting

That means fewer “cool experiments” and more boring, intentional structure.

Proxmox is the foundation, but it’s not the strategy. It’s just the tool that lets the strategy work.

The Core Philosophy: Separation Over Convenience

The biggest mistake in most home labs is collapsing everything into one flat network on one giant VM host.

It works — until it doesn’t.

I’ve moved toward clear separation:

• Management network – where Proxmox, switches, and controllers live
• Server network – where actual workloads run
• User network – normal devices
• IoT / guest / camera networks – isolated and restricted

This mirrors how real environments are structured, and more importantly, it forces you to think about access, routing, and failure boundaries.

If everything can talk to everything, you haven’t designed anything — you’ve just delayed the problem.

Proxmox: The Control Plane, Not the Junk Drawer

Proxmox isn’t where I dump random services anymore. It’s the control plane, and that distinction matters.

Instead of treating it as a place to “run stuff,” I treat it as:

• A hypervisor with clean networking boundaries
• A predictable host with minimal drift
• A system that should almost never change

Most of the actual work happens inside LXCs and VMs that can be destroyed and rebuilt at will.

If I hesitate to delete something, that’s a smell. In a real environment, rebuildability matters more than preservation.

Hardware: Boring and Replaceable

Rebuildability doesn’t mean much if the box itself is a snowflake.

I run Proxmox on an HP EliteDesk 800 G6, not because it’s special, but because it’s the opposite; it’s a common corporate refurbish, sold in volume, cheap enough that losing one isn’t a budget event.

That’s the actual point: pick hardware that’s common enough to replace or duplicate without a special order. A few reasons this matters more than it seems:

• Failure stops being a crisis. If a node dies, you buy the same (or equivalent) machine and restore, instead of scrambling to source a part.
• It sets up real redundancy. Once one node is expendable, adding a second or third for clustering and failover is a natural next step, not a special project.
• It keeps the “control plane should barely change” idea honest. A host you can’t easily replace is a host you’ll be afraid to touch — which undermines the whole philosophy.

You don’t need a rack of matched enterprise servers to think like production. You need hardware boring enough that its failure is a shrug, not an outage.

Containers vs. VMs: Be Intentional

There’s a temptation to default everything to Docker. I don’t.

• LXCs for lightweight, single-purpose services
• VMs when isolation actually matters
• Docker inside LXCs when it simplifies deployment

That last one is controversial, but it works well if you’re disciplined.

The key isn’t the tool — it’s consistency. If every service is deployed differently, you’re not building flexibility, you’re building future confusion.

Storage: Backups Are the Product

The most important part of the entire setup isn’t compute. It’s storage and backups. Everything else is replaceable.

The strategy:

• Primary workloads run on Proxmox
• Backups go to a separate storage system
• Snapshots are used for short-term recovery
• Backups are used for “oh no” moments

There’s a big difference between:

“I can roll back a bad update”

and

“I can rebuild everything after losing a node”

If you don’t have the second one, you don’t have a system — you have something that works right up until it doesn’t.

Naming and IP Strategy: Future You Matters

One of the most underrated improvements is consistency in naming and IP allocation. Not because it looks nice — because it reduces thinking when something goes wrong.

• Gateways are always .1
• Core services live in predictable ranges
• Management IPs are easy to recognize
• Temporary systems don’t collide with permanent ones

When something breaks, you shouldn’t have to guess what 10.101.200.73 is. You should already know whether it belongs there.

Networking: Where Things Actually Break

Most of the real work has gone into networking, not Proxmox. VLANs, firewall rules, DNS, NAT — this is where the complexity lives, and it’s also where most guides fall short.

A few lessons:

• Direction matters more than you’d think (in vs. out rules will get you)
• DHCP and DNS are the first things to check, not the last
• “It should work” is not a debugging strategy

The moment things started behaving like a segmented network instead of a flat LAN, everything became more predictable — even if it took more upfront thought to get there.

The Stack: Build Slowly, Not Broadly

There’s a long list of services I could run. That doesn’t mean I should run them all at once.

The current approach is simple:

1. Get the foundation stable
2. Add one service at a time
3. Make it observable (logs, uptime, access)
4. Make it recoverable
5. Then move on

It’s tempting to spin up ten containers in a weekend. It’s better to have three that you actually understand and trust.

Cloudflare + Reverse Proxy: One Door In

Externally, everything comes through a single path:

• Cloudflare Tunnel
• Reverse proxy routing internally

No exposed ports. No one-off configurations per app. If a service needs to be public, it goes through the same entry point as everything else.

That’s not just cleaner — it’s how you avoid creating invisible risk over time.

What This Actually Enables

This setup isn’t just for fun. It supports:

• Development environments that behave like production
• Internal tools that don’t rely on third-party services
• Experiments that don’t risk everything else
• A platform for building real products

That last one is the point. If your environment doesn’t make it easier to build or run something useful, it’s just expensive entertainment.

Final Thought

A good setup isn’t about how much you run. It’s about how confidently you can change it.

If you can tear something down and bring it back cleanly, you’re doing it right.

If you’re afraid to touch it, you’ve already limited what it can become.

Focus less on tools and more on structure. The tools will change. The structure is what makes everything else work.