Category: Homelab

A half-second power flicker during a ZFS scrub can corrupt your pool metadata if the write cache isn’t battery-backed. UPS battery backup isn’t optional for a NAS—it’s infrastructure. Sizing it correctly and wiring it into TrueNAS via NUT turns a catastrophic risk into a graceful shutdown.

If you’re running a homelab with any kind of persistent storage — especially ZFS on TrueNAS — you need battery backup. Not “eventually.” Now. Here’s what I learned picking one out and setting it up with automatic shutdown via NUT.

Why Homelabs Need a UPS More Than Desktops Do

A desktop PC losing power is annoying. You lose your unsaved work and reboot. A server losing power mid-write can corrupt your filesystem, break a RAID rebuild, or — in the worst case with ZFS — leave your pool in an unrecoverable state.

I’ve been running TrueNAS on a custom build (I wrote about picking the right drives for it) and the one thing I kept putting off was power protection. Classic homelab mistake: spend $800 on drives, $0 on keeping them alive during outages.

The math is simple. A decent UPS costs $150-250. A failed ZFS pool can mean rebuilding from backup (hours) or losing data (priceless). The UPS pays for itself the first time your power blips.

Simulated Sine Wave vs. Pure Sine Wave — It Actually Matters

Most cheap UPS units output a “simulated” or “stepped” sine wave. For basic electronics, this is fine. But modern server PSUs with active PFC (Power Factor Correction) can behave badly on simulated sine wave — they may refuse to switch to battery, reboot anyway, or run hot.

The rule: if your server has an active PFC power supply (most ATX PSUs sold after 2020 do), get a pure sine wave UPS. Don’t save $40 on a simulated unit and then wonder why your server still crashes during outages.

Both units I’d recommend output pure sine wave:

APC Back-UPS Pro BR1500MS2 — My Pick

This is what I ended up buying. The APC BR1500MS2 is a 1500VA/900W pure sine wave unit with 10 outlets, USB-A and USB-C charging ports, and — critically — a USB data port for NUT monitoring. (Full disclosure: affiliate link.)

Why I picked it:

• Pure sine wave output — no PFC compatibility issues
• USB HID interface — TrueNAS recognizes it immediately via NUT, no drivers needed
• 900W actual capacity — enough for my TrueNAS box (draws ~180W), plus my network switch and router
• LCD display — shows load %, battery %, estimated runtime in real-time
• User-replaceable battery — when the battery dies in 3-5 years, swap it for ~$40 instead of buying a new UPS

At ~180W load, I get about 25 minutes of runtime. That’s more than enough for NUT to detect the outage and trigger a clean shutdown.

CyberPower CP1500PFCLCD — The Alternative

If APC is out of stock or you prefer CyberPower, the CP1500PFCLCD is the direct competitor. Same 1500VA rating, pure sine wave, 12 outlets, USB HID for NUT. (Affiliate link.)

The CyberPower is usually $10-20 cheaper than the APC. Functionally, they’re nearly identical for homelab use. I went APC because I’ve had good luck with their battery replacements, but either is a solid choice. Pick whichever is cheaper when you’re shopping.

Sizing Your UPS: VA, Watts, and Runtime

UPS capacity is rated in VA (Volt-Amps) and Watts. They’re not the same thing. For homelab purposes, focus on Watts.

Here’s how to size it:

1. Measure your actual draw. A Kill A Watt meter costs ~$25 and tells you exactly how many watts your server pulls from the wall. (Affiliate link.) Don’t guess — PSU wattage ratings are maximums, not actual draw.
2. Add up everything you want on battery. Server + router + switch is typical. Monitors and non-essential stuff go on surge-only outlets.
3. Target 50-70% load. A 900W UPS running 450W of gear gives you reasonable runtime (~8-12 minutes) and doesn’t stress the battery.

My setup: TrueNAS box (~180W) + UniFi switch (~15W) + router (~12W) = ~207W total. On a 900W UPS, that’s 23% load, giving me ~25 minutes of runtime. Overkill? Maybe. But I’d rather have headroom than run at 80% and get 4 minutes of battery.

Setting Up NUT on TrueNAS for Automatic Shutdown

A UPS without automatic shutdown is just a really expensive power strip with a battery. The whole point is graceful shutdown — your server detects the outage, saves everything, and powers down cleanly before the battery dies.

TrueNAS has NUT (Network UPS Tools) built in. Here’s the setup:

1. Connect the USB data cable

Plug the USB cable from the UPS into your TrueNAS machine. Not a charging cable — the data cable that came with the UPS. Go to System → Advanced → Storage and make sure the USB device shows up.

2. Configure the UPS service

In TrueNAS SCALE, go to System Settings → Services → UPS:

UPS Mode: Master
Driver: usbhid-ups (auto-detected for APC and CyberPower)
Port: auto
Shutdown Mode: UPS reaches low battery
Shutdown Timer: 30 seconds
Monitor User: upsmon
Monitor Password: (set something, you'll need it for NUT clients)

3. Enable and test

Start the UPS service, enable auto-start. Then SSH in and check:

upsc ups@localhost

You should see battery charge, load, input voltage, and status. If it says OL (online), you’re good. Pull the power cord from the wall briefly — it should switch to OB (on battery) and you’ll see the charge start to drop.

4. NUT clients for other machines

If you’re running Docker containers or other servers (like an Ollama inference box), they can connect as NUT clients to the same UPS. On a Linux box:

apt install nut-client
# Edit /etc/nut/upsmon.conf:
MONITOR ups@truenas-ip 1 upsmon yourpassword slave
SHUTDOWNCMD "/sbin/shutdown -h +0"

Now when the UPS battery hits critical, TrueNAS shuts down first, then signals clients to do the same.

Monitoring UPS Health Over Time

Batteries degrade. A 3-year-old UPS might only give you 8 minutes instead of 25. NUT tracks battery health, but you need to actually look at it.

I have a cron job that checks upsc ups@localhost battery.charge weekly and logs it. If charge drops below 80% at full load, it’s time for a replacement battery. APC replacement batteries (RBC models) run $30-50 on Amazon and take two minutes to swap.

If you’re running a monitoring stack (Prometheus + Grafana), there’s a NUT exporter that makes this trivial. But honestly, a cron job and a log file works fine for a homelab.

What About Rack-Mount UPS?

If you’ve graduated to a proper server rack, the tower units I mentioned above won’t fit. The APC SMT1500RM2U is the rack-mount equivalent — 2U, 1500VA, pure sine wave, NUT compatible. It’s about 2x the price of the tower version. Only worth it if you actually have a rack.

For most homelabbers running a Docker or K8s setup on a single tower server, the desktop UPS units are plenty. Don’t buy rack-mount gear for a shelf setup — you’re paying for the form factor, not better protection.

The Backup Chain: UPS Is Just One Link

A UPS protects against power loss. It doesn’t protect against drive failure, ransomware, or accidental rm -rf. If you haven’t set up a real backup strategy, I wrote about enterprise-grade backup for homelabs — the 3-2-1 rule still applies, even at home.

The full resilience stack for a homelab: UPS for power → ZFS for disk redundancy → offsite backups for disaster recovery. Skip any layer and you’re gambling.

Go buy a UPS. Your data will thank you the next time the power blinks.

Free market intelligence for traders and builders: Join Alpha Signal on Telegram — daily macro, sector, and signal analysis, free.

References

1. APC by Schneider Electric — “How to Choose a UPS”
2. TrueNAS Documentation — “Configuring Network UPS Tools (NUT)”
3. CyberPower Systems — “What is Pure Sine Wave Output and Why Does It Matter?”
4. NUT (Network UPS Tools) — “NUT User Manual”
5. OpenZFS — “ZFS Best Practices Guide”

Frequently Asked Questions

The $300/Month Problem

I hit my OpenAI API billing dashboard last month and stared at $312.47. That’s what three months of prototyping a RAG pipeline cost me — and most of those tokens were wasted on testing prompts that didn’t work.

Meanwhile, my TrueNAS box sat in the closet pulling 85 watts, running Docker containers I hadn’t touched in weeks. That’s when I started looking at Ollama — a dead-simple way to run open-source LLMs locally. No API keys, no rate limits, no surprise invoices.

Three weeks in, I’ve moved about 80% of my development-time inference off the cloud. Here’s exactly how I set it up, what hardware actually matters, and the real performance numbers nobody talks about.

Why Ollama Over vLLM, LocalAI, or text-generation-webui

I tried all four. Here’s why I stuck with Ollama:

vLLM is built for production throughput — batched inference, PagedAttention, the works. It’s also a pain to configure if you just want to ask a model a question. Setup took me 45 minutes and required building from source to get GPU support working on my machine.

LocalAI supports more model formats (GGUF, GPTQ, AWQ) and has an OpenAI-compatible API out of the box. But the documentation is scattered, and I hit three different bugs in the Whisper integration before giving up.

text-generation-webui (oobabooga) is great if you want a chat UI. But I needed an API endpoint I could hit from scripts and other services, and the API felt bolted on.

Ollama won because: one binary, one command to pull a model, instant OpenAI-compatible API on port 11434. I had Llama 3.1 8B answering prompts in under 2 minutes from a cold start. That matters when you’re trying to build things, not babysit infrastructure.

Hardware: What Actually Moves the Needle

I’m running Ollama on a Mac Mini M2 with 16GB unified memory. Here’s what I learned about hardware that actually affects performance:

Memory is everything. LLMs need to fit entirely in RAM (or VRAM) to run at usable speeds. A 7B parameter model in Q4_K_M quantization needs about 4.5GB. A 13B model needs ~8GB. A 70B model needs ~40GB. If the model doesn’t fit, it pages to disk and you’re looking at 0.5 tokens/second — basically unusable.

GPU matters less than you think for models under 13B. Apple Silicon’s unified memory architecture means the M1/M2/M3 chips run these models surprisingly well — I get 35-42 tokens/second on Llama 3.1 8B with my M2. A dedicated NVIDIA GPU is faster (an RTX 3090 with 24GB VRAM will push 70+ tok/s on the same model), but the Mac Mini uses 15 watts doing it versus 350+ watts for the 3090.

CPU-only is viable for small models. On a 4-core Intel box with 32GB RAM, I was getting 8-12 tokens/second on 7B models. Not great for chat, but perfectly fine for batch processing, embeddings, or code review pipelines where latency doesn’t matter.

If you’re building a homelab inference box from scratch, here’s what I’d buy today:

• Budget ($400-600): A used Mac Mini M2 with 16GB RAM runs 7B-13B models at very usable speeds. Power draw is laughable — 15-25 watts under inference load.
• Mid-range ($800-1200): A Mac Mini M4 with 32GB lets you run 30B models and keeps two smaller models hot in memory. The M4 with 32GB unified memory is the sweet spot for most homelab setups.
• GPU path ($500-900): If you already have a Linux box, grab a used RTX 3090 24GB — they’ve dropped to $600-800 and the 24GB VRAM handles 13B models at 70+ tok/s. Just make sure your PSU can handle the 350W draw.

The Setup: 5 Minutes, Not Kidding

On macOS or Linux:

curl -fsSL https://ollama.com/install.sh | sh
ollama serve &
ollama pull llama3.1:8b

That’s it. The model downloads (~4.7GB for the Q4_K_M quantized 8B), and you’ve got an API running on localhost:11434.

Test it:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Explain TCP three-way handshake in two sentences.",
  "stream": false
}'

For Docker (which is what I use on TrueNAS):

docker run -d \
  --name ollama \
  -v ollama_data:/root/.ollama \
  -p 11434:11434 \
  --restart unless-stopped \
  ollama/ollama:latest

Then pull your model into the running container:

docker exec ollama ollama pull llama3.1:8b

Real Benchmarks: What I Actually Measured

I ran each model 10 times with the same prompt (“Write a Python function to merge two sorted lists with O(n) complexity, with docstring and type hints”) and averaged the results. Mac Mini M2, 16GB, nothing else running:

*The 70B model technically ran on 16GB with aggressive quantization but spent half its time swapping. I wouldn’t recommend it without 32GB+ RAM.

For context: GPT-4o through the API typically returns 50-80 tokens/second, but you’re paying per token and dealing with rate limits. 38 tokens/second from a local 8B model is fast enough that you barely notice the difference when coding.

Making It Useful: The OpenAI-Compatible API

This is the part that made Ollama actually practical for me. It exposes an OpenAI-compatible endpoint at /v1/chat/completions, which means you can point any tool that uses the OpenAI SDK at your local instance by just changing the base URL:

from openai import OpenAI

client = OpenAI(
    base_url="http://192.168.0.43:11434/v1",
    api_key="not-needed"  # Ollama doesn't require auth
)

response = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "Review this PR diff..."}]
)
print(response.choices[0].message.content)

I use this for:

• Automated code review — a git hook sends diffs to the local model before I push
• Log analysis — pipe structured logs through a prompt that flags anomalies
• Documentation generation — point it at a module and get decent first-draft docstrings
• Embedding generation — ollama pull nomic-embed-text gives you a solid embedding model for RAG without paying per-token

None of these need GPT-4 quality. A well-prompted 8B model handles them at 90%+ accuracy, and the cost is literally zero per request.

Gotchas I Hit (So You Don’t Have To)

Memory pressure kills everything. When Ollama loads a model, it stays in memory until another model evicts it or you restart the service. If you’re running other containers on the same box, set OLLAMA_MAX_LOADED_MODELS=1 to prevent two 8GB models from eating all your RAM and triggering the OOM killer.

Network binding matters. By default Ollama only listens on 127.0.0.1:11434. If you want other machines on your LAN to use it (which is the whole point of a homelab setup), set OLLAMA_HOST=0.0.0.0. But don’t expose this to the internet — there’s no auth layer. Put it behind a reverse proxy with basic auth or Tailscale if you need remote access.

Quantization matters more than model size. A 13B model at Q4_K_M often beats a 7B at Q8. The sweet spot for most use cases is Q4_K_M — it’s roughly 4 bits per weight, which keeps quality surprisingly close to full precision while cutting memory by 4x.

Context length eats memory fast. The default context window is 2048 tokens. Bumping it to 8192 with ollama run llama3.1 --ctx-size 8192 roughly doubles memory usage. Plan accordingly.

When to Stay on the Cloud

I still use GPT-4o and Claude for anything requiring deep reasoning, long context, or multi-step planning. Local 8B models are not good at complex architectural analysis or debugging subtle race conditions. They’re excellent at well-scoped, repetitive tasks with clear instructions.

The split I’ve landed on: cloud APIs for thinking, local models for doing. My API bill dropped from $312/month to about $45.

What I’d Do Next

If your homelab already runs Docker, adding Ollama takes 5 minutes and costs nothing. Start with llama3.1:8b for general tasks and nomic-embed-text for embeddings. If you find yourself using it daily (you will), consider dedicated hardware — a Mac Mini or a used GPU that stays on 24/7.

The models are improving fast. Llama 3.1 8B today is better than Llama 2 70B was a year ago. By the time you read this, there’s probably something even better on Ollama’s model library. Pull it and try it — that’s the beauty of running your own inference server.

Related Reading

• Best Drives for TrueNAS in 2026 — if you’re building a homelab server
• UPS Battery Backup for Your Homelab — protect your hardware investment
• Docker Compose vs Kubernetes for Homelabs — choosing the right orchestration

Full disclosure: Hardware links above are affiliate links.

📡 Want daily market intelligence with the same no-BS approach? Join Alpha Signal on Telegram for free daily signals and analysis.

References

1. Ollama — “Ollama Documentation”
2. GitHub — “LocalAI: OpenAI-Compatible API for Local Models”
3. GitHub — “vLLM: A High-Throughput and Memory-Efficient Inference and Serving Library for LLMs”
4. TrueNAS — “TrueNAS Documentation Hub”
5. Docker — “Docker Official Documentation”

Frequently Asked Questions