YouTubeRssEmail

Words & Audio About Nothing

4 8 15 16 23 42

How I Set Up Ollama on Unraid (And What I Learned the Hard Way)

Running a local LLM sounds simple until you actually try it. Install Ollama, pull a model, start chatting – that’s the pitch. The reality involves GPU passthrough that almost worked, a model that ate all my RAM, and a late-night session trying to figure out why the container kept crashing. I’ve done that part so you have a head start.

Here’s how I actually got Ollama running on Unraid, including the mistakes I made along the way.

Why Bother Running Local LLMs at All

The honest answer is privacy and cost. I use AI tools constantly for work – writing, coding, summarizing. Most of that work is fine to send to a cloud API. But some of it isn’t. Client documents, medical information, anything I don’t want stored on someone else’s servers. A local model solves that without relying on a VPN policy I can’t fully verify.

There’s also the cost angle. Once your server is already running 24/7, the marginal cost of adding Ollama is basically zero. At heavy API usage rates, local inference pays for itself in GPU cost within six months.

The Hardware Reality Check

Ollama runs on CPU, but it runs well on GPU. The difference is dramatic – a 7B parameter model might take 30 seconds per response on CPU and under 2 seconds with a decent GPU. If you’re doing anything interactive, you need GPU acceleration.

I’m running an NVIDIA RTX 3060 with 12GB VRAM. That’s enough for most 7B and 13B parameter models at full precision, and 70B models at 4-bit quantization. The 12GB VRAM limit is real – if the model doesn’t fit, Ollama falls back to CPU for the overflow layers and performance tanks.

If you don’t have a discrete GPU, you can still run Ollama on CPU with enough RAM. 32GB gets you to 13B models comfortably. 64GB opens up 34B models. It’s slow but it works for non-interactive tasks like batch summarization.

Installing Ollama on Unraid

There are two good paths: the Community Applications plugin (search for “Ollama”) or a manual Docker template. I went manual because I wanted more control over GPU assignment.

The Docker template basics:

  • Image: ollama/ollama:latest
  • Port: 11434 (both host and container)
  • Volume: /mnt/user/appdata/ollama:/root/.ollama
  • Runtime: nvidia (for GPU passthrough)

That last line is where people get stuck.

GPU Passthrough: The Part Nobody Explains Well

For NVIDIA GPU passthrough in Unraid Docker containers, you need the NVIDIA driver plugin installed from Community Applications. It’s listed as “Nvidia-Driver” and it adds the necessary runtime support.

After installing the plugin, go to your Docker container settings and look for the “Extra Parameters” field. Add --runtime=nvidia. Then add two environment variables: NVIDIA_VISIBLE_DEVICES=all and NVIDIA_DRIVER_CAPABILITIES=all.

The thing that caught me: if your GPU is also assigned to a VM (I use mine for a Windows gaming VM), you can’t pass it to Docker and a VM at the same time. You have to pick one. I now stop the Windows VM when I want to use Ollama heavily, and stop the Ollama container when gaming. It’s not elegant, but it works for my usage pattern.

Setting Up Open WebUI

Ollama’s API is great, but you probably want a chat interface. Open WebUI is the best one I’ve found. It connects to Ollama, supports multiple models, has conversation history, and can do image analysis with vision models.

Deploy it as a second Docker container. The key config is setting the Ollama API URL to your server’s IP, not localhost – something like http://192.168.1.x:11434. If you use localhost it’ll try to connect from inside the container and fail.

Which Models Are Actually Worth Running

After testing most of the popular options, here’s what I actually use:

Llama 3.1 8B – My daily driver. Fast, capable, fits in 8GB VRAM comfortably. Good for writing assistance, code review, quick Q&A. Pull it with ollama pull llama3.1:8b.

Llama 3.1 70B Q4 – The heavy one. Takes about 40GB RAM/VRAM to run. I offload most layers to RAM and use the GPU for inference. Slower but noticeably smarter for complex tasks. Worth having for anything where quality matters.

Mistral 7B – Smaller than Llama 3.1 8B but surprisingly capable. I use it when I need something fast on CPU-only.

Nomic Embed Text – Not a chat model – an embedding model. Essential if you want to build a local RAG (retrieval augmented generation) setup. Small and fast.

The Mistakes I Made

I pulled too many models at once. Each model is 4-8GB. My appdata drive ran out of space and the container kept crashing with cryptic errors. Check your free space before pulling models, and set a dedicated path on a drive with room to grow.

I tried to run Ollama and Plex at the same time during a 4K transcode. The GPU can’t serve two masters. The transcode stuttered and the Ollama response was 3x slower. If you’re sharing a GPU between media and AI, set your Plex hardware transcoding to “when available” and accept the tradeoff.

I also didn’t set a context length limit early on. Some models default to huge context windows that eat RAM even when you don’t need them. In your Open WebUI model settings, set a max context of 4096 unless you specifically need more.

Is It Worth It

For me, yes. The ability to run a capable LLM privately, on hardware I own, without a per-token cost is useful. The setup friction is real but it’s a one-time cost. Once it’s running it just works.

If you don’t have a server already running, the calculus is different. A cloud API is cheaper than buying hardware you’ll only use for LLMs. But if you’ve already got an Unraid box, Ollama is one of the best things you can add to it.

Next up: my full home network setup – VLANs, local DNS, and the one machine that does too much.

Products mentioned in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T19:22:33-07:00July 24th, 2026|Categories: Blog|0 Comments

What’s Actually Running on My Unraid Server Right Now

Most homelab posts are aspirational. They show you a pristine rack, perfectly labeled cables, and a services dashboard with everything green. What they don’t show you is the three containers that are broken and just sitting there, the drive that spun up three months ago and hasn’t been checked since, and the app you installed for a project you abandoned.

This is the honest version. Here’s exactly what’s running on my Unraid server right now, what I actually use, what’s just squatting RAM, and what I wish I’d done differently when I set it up.

The Hardware

My server is a custom build in a Fractal Design Node 804. It’s got an older Intel Xeon processor, 64GB of ECC RAM, and a mix of drive sizes that would give a proper storage admin a headache. Six data drives ranging from 4TB to 10TB, a 2TB parity drive, and two SSDs in the cache pool.

If I were building from scratch today I’d honestly consider something like the LincStation N1, which ships with an Unraid license already baked in. It’s not a powerhouse, but if your workload is mostly storage and light Docker containers it’s a cleaner starting point than my Frankenserver.

Cooling matters more than people think. I’ve had drives run 10 degrees cooler just from swapping case fans. The Noctua NF-A12x25 is overkill for noise-sensitive setups but it’s the best 120mm fan you can buy and it runs practically silent under normal load.

The Docker Stack

Unraid’s Docker integration is what made me switch from a bare Debian box three years ago. No YAML files to maintain, no compose headaches, just a UI that works. Here’s what’s actually running:

Plex – The anchor tenant. Everything else exists partly to support Plex or to not interfere with Plex. I’ve got about 8TB of media organized by Radarr and Sonarr, and the server transcodes 4K without breaking a sweat.

Radarr + Sonarr + Prowlarr – The automation trio. Once you set these up and forget about them, you realize how much time you used to waste manually managing media. Prowlarr replaced Jackett for me about a year ago and I haven’t looked back.

Jellyfin – Running alongside Plex as a backup and for family members who don’t want to deal with Plex accounts. It’s gotten good. The hardware transcoding support is solid.

Nextcloud – My Google Drive replacement. I’ve got about 200GB synced across three devices. The iOS client has improved dramatically. File sync still occasionally needs a kick to restart, which is annoying, but it’s not something I’d trade back.

Vaultwarden – Self-hosted Bitwarden server. This one is load-bearing for my whole family. It syncs to all our devices, and I export a backup every week automatically. If this goes down, everyone loses their passwords. So it gets the most attention.

Immich – Photo management, Google Photos replacement. This one has leveled up fast. Face recognition, location mapping, albums, sharing – it does everything. My wife was skeptical until she saw the mobile app. Now she uses it daily.

Home Assistant – Running in a dedicated VM, not Docker. More on this in a separate post, but it needs the full VM treatment for Zigbee USB passthrough to work reliably.

Ollama + Open WebUI – Local LLM server. This is the new addition that’s gotten the most tinkering. I run Llama 3.1 8B for quick tasks and Llama 3.1 70B quantized for anything that needs real reasoning. It uses a lot of RAM.

Uptime Kuma – Monitoring dashboard for all my services. Gets a ping every 60 seconds, sends me a Telegram message if anything goes down. Simple and reliable.

Nginx Proxy Manager – Handles all my reverse proxy routing and SSL certificates. Every service gets a clean subdomain. More on this in a dedicated post.

The VMs

Unraid’s VM manager runs on KVM under the hood. I’ve got three VMs currently:

Home Assistant OS – The whole thing runs in a VM with USB passthrough for my Zigbee stick. This is the right way to run HA on Unraid. Don’t put it in Docker unless you enjoy pain.

Windows 11 – For gaming sessions when I want to play something on the living room TV over Moonlight/Sunshine streaming. It sits idle most of the time but fires up fast when I need it.

Ubuntu dev box – A clean Linux environment for projects I don’t want running on my Mac. Docker experiments, random builds, things I might blow up. This VM gets nuked and rebuilt every few months.

What’s Broken and Just Sitting There

Authentik – I tried to set up proper SSO across all my services. Got it halfway working, then hit a wall with Nextcloud integration, and it’s been sitting broken for four months. Every time I open the UI I feel vaguely guilty.

Portainer – Installed it to manage Docker on a second machine. The second machine went away. Portainer is still there doing nothing.

A Minecraft server I set up for my kid in 2024 and haven’t touched since. It’s using 2GB of RAM.

What I’d Do Differently

I’d start with a UPS from day one. I added one later and it caught two power blips in the first month. An unexpected shutdown mid-parity check is a bad day. Get a good unit – I use an APC BX1500M and it’s been rock solid.

I’d also plan my cache drive setup before I needed to expand it. I added the second SSD to the cache pool nine months in, which meant a parity rebuild and a couple hours of anxiety. Plan for two cache drives from the start.

The other thing – document everything. Which port maps to which service, why you chose that configuration, what that weird env variable does. I have a plaintext file for this now. It saved me twice last month when I was troubleshooting something I’d set up a year ago.

What’s Next

The next post goes deep on Ollama: how I set it up on Unraid, what I learned the hard way about GPU passthrough, and which models are actually worth running locally versus just using the API. That one’s coming Thursday.

Products mentioned in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T19:22:23-07:00July 21st, 2026|Categories: Blog|0 Comments

The Case for Self-Hosted AI: Privacy, Cost, and Control

I’ve been making this case to myself and to friends for about a year now, and I want to try to make it clearly in one place, without overstating it.

The privacy argument is the most intuitive but probably the least practically decisive for most people. When you use cloud AI tools in a browser, your queries and context go to a third party’s servers. Depending on the provider and the account tier, that data may be used for training, may be reviewed by humans, may be retained indefinitely. For people who use AI to think through personal decisions, family situations, financial choices, or anything else they’d keep off a shared Google Doc, that’s a real consideration. Self-hosted AI keeps that data on your hardware. You’re trusting yourself, your network security, and your backup practices instead of a company’s data policy. The risk is different, not gone. Whether the difference matters depends on what you’re doing with AI. Part of taking that responsibility seriously is actually securing your own perimeter; I use a YubiKey 5 NFC on every account that touches the server and the WordPress admin logins.

The cost argument is more concrete and more case-specific. Cloud AI subscriptions tend to be flat monthly rates. If you use AI heavily, they’re often a good deal. If you use it inconsistently, you pay for headroom you don’t use. A self-hosted setup has high upfront cost, the hardware, and low ongoing cost. Once the infrastructure is in place, running local models is essentially free. For tasks that genuinely need a frontier model, pay-per-token API calls are often cheaper than flat subscriptions for variable usage. My personal cost dropped significantly when I moved to self-hosted plus targeted API calls, but that’s specific to my usage pattern. It’s worth calculating for yours before assuming it’ll work out the same way.

The control argument is the one I find most compelling and the hardest to communicate quickly. Control means the AI knows your environment because you gave it that knowledge deliberately. It means the AI can act on your systems because you provisioned those tools. It means the memory of your infrastructure, your preferences, your past decisions, lives in files on your hardware that you can read, edit, and correct. You’re not dependent on a provider’s memory feature, a company’s API stability, or a subscription tier that includes the capabilities you need. That independence has a real cost in setup time and maintenance, but what you get for it is an AI that’s actually integrated into your life instead of one that starts fresh every session.

None of these arguments are absolute. Cloud AI tools are good. They have world-class models, simple interfaces, massive investment in reliability and safety. For someone who wants good AI with no operational overhead, a Claude or ChatGPT subscription is a completely reasonable choice. The self-hosted path is worth it for people who want deeper integration, care about data residency, or are already running home infrastructure and find the incremental overhead acceptable.

Where I’ve landed is that the real question is what degree of integration with your own environment is worth what degree of operational overhead. For me, the integration is worth it. An AI that knows my sites, my agents, my server topology, and my recurring tasks is more useful to me than a smarter AI that knows nothing about any of it.

That’s been the through-line of this whole series. Not that self-hosted AI is better, but that the integration is what makes AI actually useful at home. If any of this series has been useful, or if you’ve built something similar and made different choices, I’d like to hear about it in the comments.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:31:00-07:00July 18th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

What I’ve Learned After Six Months Running AI Agents at Home

Six months ago I had a server, some model weights, and a vague plan. The plan worked out, but not in the ways I expected, and some things I was confident about turned out to be wrong.

The biggest surprise was how much the value came from memory and context rather than capability. I expected to be impressed by what the agents could do. What actually made the difference was that they knew my environment. What actually landed for me is that Wren never needs me to re-explain which WordPress site uses which credentials. That accumulated context is the real return on the setup investment.

I was wrong about how much I’d want autonomous operation. When I started I imagined agents running in the background making things happen. What I actually prefer is a setup where agents do the information-gathering and I make the calls. The most valuable loop isn’t “agent acts, I find out later.” It’s “agent finds out, I act.” That shift changed how I configured permission levels and approval requirements, making them stricter than my initial instincts suggested.

Tool quality matters more than model quality, within limits. Early on I focused a lot on which model I was running. Over time I noticed that agents with clear tool access, good memory, and well-defined scope outperformed agents with better models but fuzzier configurations. An agent that can reliably call the right tool with the right parameters is more useful than one that reasons well but can’t act. The two aren’t in opposition; you want both, but if I had to fix one first it’s the tools.

Scope discipline turned out to be hard to maintain. Agents naturally accumulate responsibilities over time. You add a small exception here, a new tool there, and three months later you have an agent whose domain you couldn’t clearly define if someone asked. I’ve had to pull back and rewrite configurations a couple of times to restore clear boundaries. This is ongoing work, not a one-time setup problem.

The operational overhead is real but manageable. I spend maybe an hour a month maintaining the stack: checking that containers are healthy, updating Ollama or models, reviewing and updating memory files when the state of something changes. That’s much less than I feared going in. The Unraid base helps; it handles container lifecycle reliably and I don’t spend much time keeping the platform running. The network layer is equally hands-off once set up: a TP-Link managed gigabit switch handles all the container traffic and I haven’t touched its config in months.

What changed most in how I interact with computers is how I frame tasks. Before this setup I’d navigate to something and do it. Now I often describe what I want to know or what I need to happen, and an agent traverses to the answer. That shift from “navigate and act” to “describe and delegate” sounds subtle and it has changed how I spend my time. The tedious traversal work, logging in, checking versions, looking up IDs, has mostly moved to agents. I do more deciding and less navigating.

What I’d do differently: I’d write the memory files before I needed them instead of building them up reactively. I’d define agent scopes in writing before I started configuring tools. And I’d spend less time on model selection early on and more time on making sure the tool connections were solid.

Six months in, the setup earns its overhead. I’m not going back to managing this manually.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:29:38-07:00July 15th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

How I Manage Three WordPress Sites with an AI Agent

Three WordPress sites sounds like a small number until you actually have to maintain all of them. Plugin updates, theme updates, checking for broken links, keeping an eye on drafts, knowing what’s published where. None of it is hard individually; it’s the accumulated cognitive overhead of keeping track of three separate environments that turns into friction over time.

Wren is the agent I’ve configured to handle that overhead. She\’s more like a very informed assistant who knows the current state of all three sites and can surface what needs attention. When I ask her what’s pending, she actually knows, because she has persistent memory with the site inventories: which plugins are installed, which version, what’s changed since we last looked.

The way she touches WordPress isn’t through a browser; it’s through WP-CLI commands run inside the Docker containers on my Unraid server. To run those commands, she delegates to Apex, the infrastructure agent, who has SSH access to the server and can exec into the right container. The chain looks like: I ask Wren, Wren asks Apex, Apex runs the command, the result comes back up the chain. It sounds like a lot of steps and in terms of configuration it was, but once it was set up it just works. The hardware running this doesn’t have to be a full tower; a capable mini PC like the Beelink SER5 Pro has enough headroom to run the agent stack and several Docker containers at the same time.

What Wren handles without much friction: checking plugin update status across all three sites, reading post lists and draft counts, pulling content for me to review, writing draft posts and saving them locally for my review. Those are all read operations or local writes. They don’t require my approval because they don’t change anything in production.

What still requires my explicit sign-off: any plugin update, any theme change, publishing a post, any database operation. The rule is simple and hard-coded into her configuration. She will not take a state-changing action on a live site without a clear go-ahead from me in that conversation. I set that rule early because the failure mode of an AI agent running an update that breaks a site is much worse than the inconvenience of typing “go ahead.”

The part that still requires me most is content direction. Wren can write a post draft if I give her a topic and the right context, but I still make every editorial decision. What angle to take, what to include, whether the draft is ready to publish. She handles the mechanical side of content management well, the filing, the tracking, the formatting, the metadata, but she’s an executor of editorial intent rather than a source of it.

The surprising benefit has been the accumulated site knowledge. Because Wren keeps memory files for each site, she knows things like which Avada theme version is running on elembemedia, what the affiliate disclosure policy is, what the most recent published post was and when. I no longer have to look any of that up. Over time, that knowledge base has become the most valuable thing about the setup, more valuable than any individual task she automates.

The honest limitation is that anything requiring visual inspection of the site still requires me to open a browser. Wren can’t see what a page looks like. She can tell me what content is in the database, but not whether it’s rendering correctly. For a visual platform like WordPress, that’s a real gap.

If you’re running WordPress yourself and want to ask about specific WP-CLI commands or how I’ve structured the agent configuration, leave a comment.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:29:27-07:00July 12th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

Running Local LLMs on Unraid

The first local model I ran took about 45 seconds to respond to a simple question. I almost gave up right there. The model was too big for my VRAM, the quantization was wrong, and I hadn’t understood yet that “running a local LLM” and “running a usable local LLM” are meaningfully different things.

I run Ollama inside a Docker container on Unraid. The container gets passed through to an NVIDIA GPU, which handles all the inference. The host is a Ryzen 9 5900X on an ASUS TUF Gaming X570-Plus (Wi-Fi) board. Getting GPU passthrough working was the first real obstacle. Unraid handles it through its Docker GPU assignment settings, but you have to make sure the NVIDIA container toolkit is installed and the container is configured to use it. There are Unraid forum threads on this; I won’t reproduce the whole process here, but it took me longer than I expected because the error messages weren’t obvious about what was actually wrong.

The hardware question matters more than the model question, at first. Most consumer GPUs in the 8-12GB VRAM range can run 7B or 8B parameter models fully in memory and respond in a few seconds. That’s where I’d start. The models in that range, Llama 3, Mistral, Gemma, Qwen, have gotten good enough over the past year that the quality is genuinely useful for most everyday tasks. Quantized versions, typically Q4 or Q5, cut memory requirements significantly with a modest quality tradeoff. For anything that’s not critical reasoning, the tradeoff is worth it.

What I actually run daily is a quantized Llama 3 8B for quick, low-stakes queries and a mid-size model in the 13-20B range for tasks where quality matters more than speed. The 8B model responds in 2-4 seconds on my hardware, which feels fast enough to be comfortable. The larger model takes 15-25 seconds per response, which I find acceptable for deliberate tasks but too slow for conversational back-and-forth.

The models I don’t run locally are the ones where I genuinely need top-tier reasoning or writing quality. For those I send API calls to Anthropic. The local models are good for information retrieval, summarization, drafting, code explanation, and routine agent tasks. They’re not good enough to replace a frontier model for complex multi-step reasoning or polished writing that goes on the internet. Knowing that line has saved me a lot of frustration.

Unraid’s container management makes it fairly easy to keep Ollama updated and to pull new models. The Ollama API makes it straightforward to switch which model a request goes to. The practical challenge is storage: model weights pile up fast. A handful of models can eat 50-100GB without trying hard. I keep the ones I actually use and delete the rest. The Unraid array handles the storage; I’ve dedicated a Samsung 860 EVO 1TB as a cache SSD specifically for models so loading times stay fast.

One thing I wish I’d known earlier: the model name matters, but the quantization label matters almost as much. “Llama 3 8B” can mean very different performance depending on whether it’s Q2, Q4, Q5, or Q8. I run Q4 as a default, Q5 when I want a bit more quality on a task that warrants it. Q8 is overkill for most things and Q2 degrades quality more than I find acceptable.

If you’re curious about specific model recommendations for your VRAM budget, feel free to drop the specs in a comment and I’ll give you my current take.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:29:17-07:00July 9th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

OpenClaw vs. n8n vs. Home Assistant for Home AI

People ask me fairly often why I’m not using n8n or Home Assistant for my AI automation. The short answer is that they solve different problems, and understanding the difference saves you a lot of time trying to make the wrong tool fit.

Home Assistant is exceptional at what it does: device state, automations triggered by sensors, physical environment control. If your goal is “turn the lights off when I leave” or “notify me when the garage is open,” Home Assistant is the right tool and it’s very good at it. It runs well on modest dedicated hardware; the CanaKit Raspberry Pi 5 Starter Kit PRO is a popular entry point if you want a low-power box that stays out of the way. When people ask about using it for AI workflows, what they usually mean is plugging in an LLM integration so they can ask questions via voice assistant. That works, up to a point. But Home Assistant’s data model is built around devices and states, not conversational context or tool execution. An LLM living inside Home Assistant is a capability bolted on top of a very different architecture. It handles simple tasks fine and gets awkward fast when you need the AI to actually do things.

n8n is a workflow automation tool with a visual canvas. It’s legitimately powerful for connecting APIs, transforming data, and running scheduled jobs. I used it for a while and it’s good at stringing together a sequence of discrete steps: “when this webhook fires, call this API, transform the result, post it here.” Where it struggles is with the kind of reasoning loop that AI agents actually need. An AI picks what to do next at each step based on what it found. n8n’s flow model doesn’t fit that pattern naturally. You end up with workflows that have conditional branches trying to approximate reasoning, and those get brittle quickly.

OpenClaw, which is what I run, is built specifically around agent management. The core model is: here’s a persistent agent with a defined identity, memory, and tool access. The agent receives messages, reasons about them, calls tools, and responds. Tool access is explicit and permissioned. Memory persists between sessions. Multiple agents can coordinate through a message-passing model. That structure maps well to how AI agents actually work, because it was designed for that use case rather than adapted from something else.

The tradeoff is that OpenClaw is more complex to set up than either of the others, and the ecosystem is smaller. With n8n and Home Assistant you get large communities, extensive integrations, good documentation for common use cases. With OpenClaw you get better architectural fit for agents and more bespoke troubleshooting.

My actual setup uses all three, loosely. Home Assistant handles devices and sensors; it does that well and I have no reason to change it. n8n still runs a few periodic data jobs that don’t need any AI reasoning. OpenClaw handles everything that involves an AI agent taking action. They don’t compete because they don’t overlap much in practice.

If I were building something new today and the use case was specifically AI agents that manage services, respond to messages, and take actions on real systems, I’d go straight to OpenClaw or a similar agent-native platform. If the use case was device automation with a sprinkle of LLM, I’d start with Home Assistant. If it was data pipeline automation between external services, n8n is still strong. The mistake is treating any of them as a general-purpose solution when they’re each optimized for something specific.

What are you trying to automate? That question usually points pretty clearly at which tool belongs in the stack.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:29:07-07:00July 6th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

The Self-Hosted AI Stack I’d Build If I Were Starting Over

I took a winding road to get my current AI homelab working. I’d make different choices if I were starting from scratch, and most of them would come down to doing less sooner rather than more.

The first thing I’d do is separate the model serving layer from everything else. Ollama as a standalone container, exposed on a private network, nothing else bundled in. A lot of guides will tell you to start with a full OpenWebUI stack, and OpenWebUI is fine, but it creates a coupling that makes things harder to reason about later. If your UI and your model server are the same deployment, you end up with friction when you want to swap one out or add a second frontend. Keep them separate from the start.

For hardware, I’d be more honest with myself about the model size tradeoff. My current build is a Ryzen 9 5900X on an ASUS TUF Gaming X570-Plus (Wi-Fi) board, and it handles everything I throw at it for inference routing and container management. A 7B parameter model runs well on consumer GPU memory, responds quickly, and handles most practical tasks. I spent too long trying to run 34B models on hardware that wasn’t really right for them, getting slow responses, and convincing myself the capability justified the latency. It usually didn’t. For day-to-day assistant work, a well-quantized 7B or 8B model is more useful than a sluggish 34B. Save the bigger models for tasks where reasoning quality actually matters.

The gateway layer is where I’d invest more early effort. This is the piece that connects LLM inference to real tools: file system access, APIs, shell commands, memory. I’m running OpenClaw for this. If I were starting fresh, I’d still choose a purpose-built gateway over trying to wire this together myself with n8n or LangChain. The operational overhead of maintaining custom orchestration code is real. A gateway that’s designed to manage agent lifecycles, credential handling, and tool permissions out of the box is worth the setup time.

Memory is something I’d take seriously from day one. The difference between an AI that knows the state of your environment and one that starts fresh every session is enormous in practice. That means deciding early on where state lives, how agents read and write it, and what format it’s in. Markdown files on a shared volume have worked well for me: human-readable, easy to edit when something’s wrong, git-friendly if you want version history.

For API keys and credentials, I’d use a secrets directory with tight permissions from the start rather than environment variables scattered across docker-compose files. It’s easier to audit, easier to rotate, and easier to scope to specific containers when something needs to change. This sounds like overkill when you’re standing up one container. It pays off when you have eight.

The thing I’d skip entirely on a first build is trying to run everything locally. Ollama handles local inference well. But for tasks that genuinely need a frontier model, the cost of API calls is low and the capability gap is large enough to matter. Don’t try to replace Claude with a local model for complex reasoning. Use local models where they’re good enough and cloud APIs where they’re not. That hybrid approach is cheaper and more capable than either extreme.

Finally, I’d document my container layout before it gets complicated. Which container serves which purpose, which ports are mapped, what credentials it needs. This sounds tedious and it is. Three months later when you’re trying to figure out why something stopped working, you’ll be glad you did it.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-18T11:46:47-07:00July 3rd, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

What Multi-Agent AI Actually Looks Like at Home

There’s a version of multi-agent AI that lives in conference talks: perfectly orchestrated systems where dozens of specialized agents collaborate on complex tasks without human input. What I have is messier and more practical, which makes it more interesting.

Here’s a real example from last week. I wanted to update the plugins on one of my WordPress sites. Normally that’s a login, navigate to updates, click apply, wait, done. With agents, I sent one message to Juniper: “Check elembemedia for plugin updates and tell me what’s pending.” Juniper delegated to Wren, who delegated to Apex, who ran a WP-CLI command inside the Docker container and returned a list. Juniper summarized it back to me. Nothing got updated without my go-ahead. But the information-gathering part, which is tedious and requires knowing which container maps to which site, happened in about 30 seconds.

That workflow is the pattern. The pattern is: gather the information, stage the action, I approve or redirect. The agents handle the boring traversal work: knowing which credentials to use, which container to exec into, which API endpoint to call. I stay in the loop for decisions.

Wren’s day-to-day is mostly WordPress housekeeping. She tracks the state of three sites: what plugins are active, what posts are published, what drafts exist. When I ask her to write a post draft, she saves it to the right folder with the right frontmatter. She won’t publish anything I haven’t explicitly signed off on. That’s a hard rule in her configuration, and it matters. The value isn’t that she does everything; it’s that she remembers everything so I don’t have to.

Apex is narrower. She has SSH access to the Unraid server and can run commands inside Docker containers. That access is deliberately constrained. She won’t run anything destructive without a confirmation loop. Her most common tasks are checking container status, running read-only WP-CLI commands, and running the actual update commands once I’ve approved what Wren found. She’s the hands; Wren is the eyes. All of this runs over a local network kept deliberately simple: a TP-Link 8-port gigabit switch handles the traffic between the server and the machines I work from. Nothing fancy; the goal is reliability.

Juniper is the coordinator, but in practice she’s less active than I expected. Most of my interactions are direct: I message Wren about WordPress stuff, I message Apex about infrastructure. Juniper is useful when I want to describe an outcome rather than a specific task and let her figure out the delegation. “What’s the update status across all three sites” is a Juniper question. “Activate the Twenty Twenty-Five theme on bacallburns” is a Wren question.

Fran handles family logistics: calendar, reminders, school schedules. Completely separate domain from the tech agents. She doesn’t have server access and doesn’t need it. Separating domains like this sounds obvious, but it takes deliberate configuration. Without clear scope boundaries, agents start trying to be helpful in ways that cross lines you didn’t know you cared about until they crossed them.

The honest limitation is that this setup requires real maintenance overhead to build initially. Defining scopes, setting up credentials, writing the memory files that give agents context about your environment: that’s a weekend of work, minimum. The return on that investment compounds over time as the agents accumulate useful state, but the upfront cost is real.

If this sounds interesting to you, the most useful thing I can suggest is starting with one agent and one domain. Get comfortable with what it can and can’t do before you start wiring agents together. The coordination layer is where complexity explodes.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:28:58-07:00June 30th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

Unraid as an AI Homelab Platform

Unraid wasn’t designed for AI workloads. It was designed for flexible storage, a simple container interface, and not requiring matching drives in your array. That’s still what it does well. But over the past year it’s become the platform I run my entire AI stack on, and the fit is better than I expected in some ways and worse in others.

The biggest win is container management. Ollama, the OpenWebUI frontend, my OpenClaw gateway, three WordPress instances, and a handful of other services all run as Docker containers managed through Unraid’s interface. Adding a new model backend or a new agent service is a few clicks and a docker-compose file. Unraid keeps them running, handles restart policies, and gives me a clean way to see resource usage across all of them. For someone who doesn’t want to maintain a full Kubernetes cluster, it’s a reasonable middle ground.

GPU passthrough is where things get more complicated. I’m running a Ryzen 9 5900X on an ASUS TUF Gaming X570-Plus (Wi-Fi) board, with an NVIDIA GPU passed through to an Ollama container for local model inference. The passthrough works, but Unraid’s VM/container GPU assignment can be finicky when you’re also trying to use that GPU for other things. I had to be deliberate about which containers got GPU access and accept that gaming on the same machine would require careful scheduling. Not a dealbreaker, but worth knowing going in.

The storage story is actually solid. I can dedicate a fast SSD cache for model weights and keep larger, less frequently accessed files on the array. I’m using a Samsung 860 EVO 1TB as the cache drive, and it keeps model load times fast. Unraid handles the tiering automatically once you set the cache rules. Model weights are big; an LLM with decent reasoning capability can be 15-40GB. Having flexible storage without needing to rethink my whole array setup was a real convenience.

Community support is a mixed bag. Unraid has an active forum and a decent app ecosystem through Community Applications. But AI-specific homelab content on Unraid is still pretty thin compared to what exists for plain Ubuntu or Proxmox. When I ran into edge cases with GPU driver versions inside containers, I was mostly on my own piecing together solutions from Ollama’s docs and Unraid threads that were only tangentially related to my problem.

Stability has been good in practice. I’ve had this stack running for months with minimal intervention. Unraid’s approach of keeping things simple, one box, one UI, no orchestration overhead, matches how I want to run this. I don’t want to spend weekends maintaining infrastructure. I want the infrastructure to run and get out of my way.

If I were advising someone choosing a platform for a first AI homelab, I’d say Unraid is a solid choice if you’re already on it or if you also want a NAS alongside your AI workload. The integrated storage and container UI are genuinely useful. If you only want AI workloads and nothing else, plain Ubuntu with Docker might be simpler to troubleshoot when things go sideways. Proxmox gives you more VM flexibility if you need it.

None of these platforms solve the fundamental challenge of home AI: the hardware has to be powerful enough to run something worth running, and that still costs real money. Unraid doesn’t change that calculus. But for managing what you already have, it handles the complexity well enough that I spend my time on the AI problems rather than the infrastructure problems.

Happy to answer questions about specific container setups or the GPU configuration if anyone’s working through the same thing.

Hardware linked in this post:

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.

2026-06-25T14:28:48-07:00June 27th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments