I read it over coffee and said yes. The space came back.

I didn't open a dashboard or SSH into anything, and I didn't have to remember which job wrote those backups. I've run this homelab for years and I'm not sure I'd have noticed that drive filling up before it actually filled up. That's the reason I built this.

What I have now is a small crew of AI agents that handles the day-to-day running of my servers. I make the decisions and they do the legwork. This post covers how it fits together, which models do which job, and what I'd do the same or differently if I started again. I've left out configs, addresses and anything else that would help someone find my house, because the ideas are the useful part.

What's an AI harness?

A language model on its own can answer questions, but it can't check a server, read a log or do anything in the world.

The harness is everything you build around the model so it can. It decides which tools the model gets, what it remembers between conversations, what it's forbidden to touch and how it reaches you. It also handles the dull parts, like schedules, retries, budgets and switching to another model when one is down.

People spend a lot of time arguing about which model is best and very little on the harness, even though that's where most of the engineering goes. A strong model inside a careless harness is a quick way to delete something you needed.

Why ZeroClaw

I tried a few agent frameworks before settling on ZeroClaw. Some wanted to own my whole stack. Others made a great ten-minute demo and then fell over the first time something unexpected happened.

ZeroClaw is small and runs on my own hardware, in a container, so my data stays at home. It was built for several agents with different jobs, and each one can have its own permissions and its own model. The safety features I care about are part of it rather than something I had to bolt on: risk levels, a list of commands each agent may run, a cap on actions per hour, and approval flows. It also schedules jobs and talks to me through a chat app, which covered the rest.

Mostly, though, I picked it because it's boring. It starts, it runs, it comes back after a restart. For something that's supposed to keep an eye on my servers at 3 a.m., that matters more than any feature list.

What I actually wanted

I didn't want an AI that does everything. I've seen where that ends up.

I wanted something closer to a careful colleague. It should look at everything and change very little without asking. It should tell me when it doesn't know something instead of guessing to sound helpful. It shouldn't cost much, it should get better over time, and it should do real work instead of looking impressive in a screenshot.

Meet the crew

I named the agents after the AI sidekicks from a certain billionaire's workshop. If I'm going to talk to my infrastructure every day, it might as well have some personality.

I only ever talk to EDITH. She's the orchestrator: she works out what I'm asking for, hands it to the right specialist and brings back one answer instead of four. She never touches the servers herself.

FRIDAY watches things. Health, stats, logs, backups, disk space. She's strictly read-only, and every report ends with a one-line verdict so I can skim.

VERONICA runs the media side: what's in the library, what's new, what's stuck, what someone has requested.

JARVIS looks after identity and access, meaning accounts, groups and who gets in where. He asks before he changes anything.

DUM-E is the builder. In the films he's the clumsy robot arm that sprays the fire extinguisher at everyone. Mine is fully enabled and working, and it's a lot less chaotic than the original. It does the hands-on build work under the same rules as the rest of the crew.

Which models run which agent

This is the question I'd have wanted answered when I started, so here it is plainly.

Using two vendors is deliberate. It keeps the bill down, and it means one provider having a bad day doesn't take everything with it, which I'll come back to.

One thing I learned the hard way: the very smallest models are good at summarising and bad at driving tools. In my setup they'd write a tool call out as plain text and never actually run it. So Flash-Lite only sorts and summarises. It never operates anything.

How it all fits together

Here's the whole picture. Follow the moving dashes.

It reads left to right, and I'll walk through one request.

I send a message in Telegram. It lands in the ZeroClaw gateway, which is the container that hosts all the agents. EDITH reads it, asks Claude what to do, and hands the job to the right specialist. That specialist calls Gemini to work out the details.

Then comes the part I care about most. The specialist doesn't get a terminal. It can only call the toolbox, a set of purpose-built commands: show stats, show backup status, read a container's logs, look up the media library, and so on. Each command does one job, refuses odd input and strips secrets from its output.

The toolbox reaches the homelab through three narrow paths. One is the Proxmox API, using a read-only token. One is an SSH gate, a locked-down login that can only run a short list of approved actions and nothing else. The third is the APIs of the apps themselves: Jellyfin, Jellyseerr, Authentik and Netdata.

Approvals mostly happen right in the Telegram chat. When something needs my say-so, EDITH posts what she wants to do with Approve and Deny buttons, and nothing happens until I tap one. For the riskiest changes there's a second check along the bottom: a one-time code sent over a separate private ntfy channel, which I have to send back before the action runs. At the top are the model providers, lined up in the order they take over when the one before goes down.

Two boxes inside the gateway don't take part in a request. Playbooks and memory hold the skills and runbooks the agents read, plus the lessons from the weekly review. Guardrails hold the risk profiles, the command allowlist and the hourly action cap. They're what keeps the whole thing in bounds.

What they actually do

Some of it runs on a schedule and some of it happens when I ask.

Every morning there's a briefing: what ran overnight, what failed, what needs a decision. During the day, alerts get sorted so only the ones worth interrupting me for reach my phone. When I'm curious about something ("how are the servers doing?", "what's new in the library?", "add that movie"), I ask in the same chat and the right agent picks it up. If something breaks, the agent proposes a fix. Small fixes it can make on its own within limits, and bigger ones wait for me. Afterwards it checks the app actually came back, because "I ran the command" and "it worked" are different statements.

Here's roughly what a conversation looks like, lightly edited:

Me: are my backups ok?

EDITH: Checking with FRIDAY.

EDITH: Mostly good. 21 of 22 systems have a backup from the last day. The router's is six days old, but that's its weekly schedule, so it's fine. One system has no backup I can actually prove from the logs. I'm calling that unknown, not fine. Want me to dig in?

That last bit matters more than it looks. Early on, it filled gaps with confident guesses. Teaching it to say "unknown" was the most useful change I made.

There's also a weekly review where the crew looks back over its own week and writes down what it learned, which it reads next time. It's early days for that part, so I won't oversell what it has taught itself so far.

Why delegate instead of one big agent

The tempting design is a single super-agent with every tool and every permission. I'd talk you out of it.

A narrow job means short instructions, and short instructions mean fewer mistakes. It also keeps the damage small when something does go wrong. FRIDAY can't delete anything because she has no way to, and JARVIS can't restart a service. Routine work doesn't need the most expensive model, which is the whole reason for the split above. And when one agent misbehaves I know exactly which one to fix, instead of untangling a four-thousand-word prompt.

It's the same reason you don't give the intern the root password. Nobody thinks the intern is bad, but the setup shouldn't depend on it.

Why this is the right pattern

If I had to compress the design into one sentence, it would be: give the AI judgement, not authority.

The model decides what's worth doing. A plain, deterministic layer decides whether it's allowed. The model can be as creative as it likes, because the rules aren't written in its prompt where it could talk itself around them. They're enforced somewhere it can't reach.

Two decisions carry most of the weight. First, the agents don't get a shell at all, only the toolbox, so you can't trick an agent into running something it was never given. Second, access is narrow on purpose: each agent connects through a path that allows a short list of actions on specific machines, and the read-only agent's credentials really are read-only.

How the bill stays small

My rule is that every question goes to the cheapest thing that can answer it properly.

Plenty of questions don't need a model at all. If a script can work out whether a disk is over 80% full, it does, and that costs nothing. Routine jobs go to Gemini 3.7 Flash, and sorting and summarising goes to Flash-Lite. Claude is kept for the thinking. Instructions that never change are cached, so I'm not paying to re-read the same playbook with every message, and there's a cap on actions per hour so a runaway loop gets stopped before it gets expensive.

I'm not going to quote my bill, because it moves around and would date this post. What I can say is that the split above is what keeps it from being alarming.

The fallback plan

Models go down. APIs get rate-limited. Providers have bad days. If everything depended on one vendor, I'd have swapped a single point of failure on a server for one on a subscription.

So there's an order. Claude goes first. If it's unavailable, the request moves to Gemini, then to OpenRouter, a marketplace that fronts many providers, and finally to a LiteLLM gateway that I host myself. That last step is the one I'm still finishing, so right now I'd call the chain three deep with a fourth on the way. I still get an answer when one fails. It might just read less well.

Human in the loop

This is the part I'm proudest of, and the reason I'm comfortable leaving it running.

Every action is sorted into one of three tiers by a policy, not by the AI's judgement in the moment.

On top of that there's a list of things no agent may restart, ever, like databases. No clever phrasing changes that, because the rule isn't in the prompt. And after any change, the agent checks that it worked and tells me, rather than just saying it's done.

What went wrong

Plenty did, which is why I trust it more now.

Early on I asked about the media server and an agent told me nobody was watching anything, because the CPU was quiet. It had no way of knowing that. It was guessing and presenting the guess as a fact. Now it reads actual session data, and "never infer what you can look up" is written into its instructions.

The backup checker was worse. It reported nearly every system as missing a backup. The backups were fine. The agent's read-only access just couldn't see them, and my tool had treated "I can't see it" as "it doesn't exist". That's where the unknown rule came from. Now it reads the job logs as evidence, and when it can't prove something it says so.

And one deploy quietly failed because of a line-ending difference between Windows and Linux, so a new command the agent needed was silently refused. Nothing crashed. I only found out because I tested it with a real question, which taught me to check that a change actually landed.

Each of these became a rule, a test or a note the crew reads.

What it can't do, deliberately

It won't make a serious change without a code from me. It won't touch the databases. It won't give me a confident answer it can't back up, and it never gets to see my secrets. I used to think of those as limitations, but they're what make it safe to leave running.

What's more, once you have the platform

The first agent is the hard one. After that, every idea is a small step, because the harness, the guardrails and the chat are already there, and a new capability is just another role with another narrow toolbox.

I'm looking at smart-home awareness, so the house and the lab can see each other, and at alerts that get smarter about what deserves my attention. The agents already search my own documentation, so "how did I set this up again?" has an answer. I also run self-tests after changes to check the whole crew still behaves, and more specialists (networking, security reviews, cost reports) are an obvious next step. None of them need new plumbing.

If I started over, I'd begin read-only and let the agents earn trust before giving them anything that can change state. I'd build commands rather than hand over a shell. I'd treat "I don't know" as a perfectly good answer, and I'd put a human on the small slice of actions that can really hurt. Everything else I'd automate.

My homelab used to be something I maintained. Now it's something I supervise, which is a better job. If you build your own crew, I'd like to hear what you call them.

The fix wasn't a smarter prompt. It was documentation, treated as part of the project itself, not something I'd get to later.

One big notes file didn't hold up

I started with a single running doc, everything in one place, added as I went. It broke down fast. A file mixing "why I chose this identity provider" with "what's currently broken" with "step three of a migration" isn't useful to me skimming it, and it isn't useful to AI trying to get oriented for one task. Everything's in there, so nothing's actually findable.

Splitting by topic

I organized things into folders by concern instead of by when something was written. Each folder covers exactly one topic and doesn't need to know what's in any of the others to make sense. Roughly, it looks like this:

The numbers aren't decoration. They enforce order — you can't reasonably start on implementation before strategy exists, and having the folder sitting there at 06 is a constant reminder of that.

Within each folder, the same few document types tend to repeat:

project/
|-- AGENTS.md
|-- CLAUDE.md
|-- GEMINI.md
|
|-- 01-strategy/
|   |-- strategy-master.md
|   |-- decision-log.md
|   |-- principles.md
|
|-- 02-infrastructure/
|   |-- infra-master.md
|   |-- capacity-notes.md
|   |-- host-inventory.md
|
|-- 03-standards/
|   |-- standards-master.md
|   |-- naming-conventions.md
|   |-- deployment-checklist.md
|
|-- 04-networking/
|   |-- networking-master.md
|   |-- identity-and-access.md
|   |-- observability-master.md
|
|-- 05-migration/
|   |-- migration-guide.md
|   |-- progress-tracker.md
|   |-- lessons-learned.md
|   |-- operations-gotchas-log.md
|
|-- 06-implementation/
|   |-- service-a/
|   |   |-- notes.md
|   |   |-- config-decisions.md
|   |-- service-b/
|   |   |-- notes.md
|   |-- service-c/
|       |-- notes.md
|
|-- 07-automation/
    |-- automation-guide.md
    |-- scripts/
    |   |-- (provisioning and integration scripts)
    |-- runbooks/
        |-- (step-by-step recovery/maintenance procedures)

Legend

AGENTS.md, CLAUDE.md, GEMINI.md — read first, every session, regardless of which model shows up.

01-strategy — the why, and the lines that don't move.

02-infrastructure — the physical/virtual shape of things.

03-standards — the conventions every new service has to follow, so nothing feels bolted on.

04-networking — how traffic, identity, and monitoring flow between everything.

05-migration — the bridge from old to new, plus a tracker and a running log of what broke and what was learned from it.

06-implementation — one folder per service, the actual build notes.

07-automation — what runs on its own, and the procedures for when something needs a human.

The numbers aren't decoration. They enforce order — you can't reasonably start on implementation before strategy exists, and having the folder sitting there at 06 is a constant reminder of that.

Within each folder, the same few document types tend to repeat:

A master doc — the settled reasoning for that topic. Changes rarely, and only with real justification.

A tracker — what's done, in progress, blocked. Updated constantly, more disposable in spirit even though I keep the history.

A log — not a tracker, a record of decisions and mistakes. Answers "why did we do it this way" and "what went wrong last time" without anyone needing to remember.

The one file every AI reads first

Sitting outside all of that is a single project-level file that isn't about the homelab itself — it's about how to work on it. What's already settled and shouldn't be re-litigated. What questions to ask before changing something. Where to look for what. Every AI session reads that file first, no matter which model shows up. It's the one thing I never have to explain twice.

What it actually gets me

Mostly speed and consistency. A new session doesn't start with me re-explaining history. It reads the relevant docs and it's oriented in minutes, not by relitigating decisions from memory — mine or its.

Nobody remembers every decision correctly after enough time passes, including me. This way, the project's memory doesn't depend on my memory or on any one session getting it right. It depends on the docs staying current — and keeping them current is itself something AI now handles, since that's exactly the kind of upkeep that used to get skipped.

If you're setting up something similar, the folder names don't matter. The separation does — one topic per space, a clear order, and one file that tells whoever (or whatever) shows up how to operate before they touch anything.

This year I had two things I didn't have before: a much clearer sense of how I'd actually want it built, and an AI capable enough to be a real partner in doing it. So I started over — properly, from architecture down — and let AI run point on a lot of the actual build. I'm calling the project EDITH.

That's the story part. Here's the part that actually matters if you're thinking about doing this yourself.

Where I actually spent time

Not writing configs. The first real chunk of time went into an architecture conversation with Claude — no code, just talking through what the homelab needed to do, what principles it had to follow, where I didn't want compromises (data ownership, single points of failure, consistent auth). That conversation became the spec. Everything after it had to justify itself against that spec.

Second chunk of time: documentation, before a single service existed. That felt backwards the first time I did it. It isn't. A homelab you're building with AI lives or dies on whether the AI can pick up exactly where it left off, and that only works if the state of the project lives somewhere outside the chat window.

How the documents are organized

I split things into a few distinct documents instead of one giant wall of notes:

A master architecture/strategy doc — the "why," rarely changes.

Domain-specific design docs — networking and observability, identity and access policy — each owned by its topic, not mixed together.

A progress tracker — what's done, what's in flight, what's blocked, updated as we go.

A decision log — why we chose what we chose, so six months from now neither of us re-litigates a settled question.

This separation matters more than it sounds like it should. When I bring AI into a session, it doesn't need the whole history — it reads the docs relevant to the task at hand and it's instantly grounded. No re-explaining, no drift.

Structurally, it's just numbered folders — strategy, infrastructure, standards, networking, migration, implementation, automation — each one scoped to a single concern. Nothing fancy. The numbering just enforces an order of operations: you can't skip to implementation before strategy exists.

Guardrails and access

AI has real access in this project — not just chat. It can SSH into my Proxmox hypervisor, spin up LXC containers, and provision them. That's a meaningfully different thing from "AI helped me write a script." It's closer to having infrastructure staff.

That access is scoped, not blanket. A few rules I hold firm on:

Anything destructive or irreversible on the existing, working homelab — I do that myself, or I approve it explicitly before it happens.

Credentials, tokens, and secrets are never something AI holds onto between sessions. They get provided fresh when needed and nowhere else.

Provisioning new infrastructure, drafting configs, writing docs, running checks — AI does that with a long leash. Touching anything already in production — short leash, human in the loop.

The rule of thumb: reversible and additive, let it run. Irreversible or subtractive, I'm the one who pulls the trigger.

What actually gets automated

New LXC provisioning end to end. Drafting the reverse proxy and auth strategy for a new service before I've thought about it myself. Updating the trackers and docs as work happens, so I'm not the one maintaining project hygiene by hand at 11pm. Catching inconsistencies between what a design doc says and what's actually running.

What doesn't: the final call on architecture changes, anything touching my existing production lab, and access control decisions. Those stay mine.

Why this beats doing it solo

A homelab is a one-person team with a day job. That's the real constraint — not skill, not curiosity, time. AI doesn't change what a homelab is, but it changes what a single person with two hours on a Tuesday night can actually get done. Documentation that would never get written otherwise, gets written. Consistency across forty services that would drift after service twelve, gets held. The stuff that used to get skipped because it's tedious and not fun — that's exactly the stuff AI is good at picking up.

The owner still has to hold command, though. AI will happily generate a confident, well-reasoned, wrong answer. The job shifts from "do everything yourself" to "review everything that matters and let go of everything that doesn't."

Where it's a genuinely great way to learn

I understand my own architecture better now than any homelab I've built solo — because I had to explain it, defend it, and watch something push back on it in real time. Explaining a design to something that asks good questions is one of the fastest ways to actually learn the design.

Where AI got it wrong

It's happened. A couple of times AI proposed a networking approach that technically worked but didn't match a principle we'd agreed on three weeks earlier — because that context lived in a doc it hadn't read for that session. A couple of times it was overconfident about something that needed a second opinion.

Every one of those goes into the decision log as a lesson, not just a fix. The point isn't a spotless project — it's a project that gets more grounded every time something goes wrong.

Being deliberate about tokens

Running AI as a genuine collaborator on a real project uses real usage — and burning through it carelessly is its own failure mode. A couple of things that changed how I work:

I don't ask AI to redo work it's already grounded in — the docs exist so I don't have to re-explain, and it doesn't have to re-derive.

Not every task needs the most capable model running at full context. Some of the more repetitive or narrowly-scoped work gets offloaded to a second model — Gemini, in my setup — while Claude stays focused on architecture-level decisions and keeps an eye on the overall picture. It's less "one AI does everything" and more "the right amount of model for the task," with someone still watching the whole board.

Git as the coordination layer

When more than one model is touching the project, git is what keeps it sane. Claude and Gemini work on separate branches. Nothing lands on the main line without review — Claude reviews Gemini's branch, I review the merges that matter. It's a normal engineering workflow, just with more than one contributor that happens to be an AI.

It's not just code

This is the part that surprised me most. This isn't "AI helped me write a script." AI has SSH'd into my Proxmox host, spun up containers, and worked inside them. It operates at the infrastructure layer, not just the text-editor layer. That's a different category of collaborator than most people picture when they hear "AI homelab."

How the layers fit together

Without getting into configs — the shape of it is a few distinct layers, each with a clear job, each built by walking through the same process above:

A network layer, where a single reverse proxy is the front door for everything, so there's one place that governs how traffic reaches any service.

An identity layer sitting in front of that — single sign-on, so "who has access to what" is one decision made in one place, not re-implemented per service.

A service layer — the actual applications, media, tools, whatever the lab is for — that all inherit the same entry point and the same identity rules instead of reinventing them.

An observability layer wrapping around all of it, watching without being in the critical path, so I know what's happening without it being able to break what's happening.

Each of those layers went through the same loop: architecture conversation, documentation, delegation, review. That loop is really the whole system. The layers are just where it gets applied.

Next: the-document-system-that-keeps-ai-grounded

If you’re here because:

• you love AI experiments 🧪

• you’re mildly terrified of autonomous agents 🤖

• or you just enjoy watching software do questionable things on the internet

…you’re in the right place.

This post is intentionally not super technical by default. If at any point your brain whispers “yeah okay this is getting too nerdy”, I’ll clearly mark where you can jump ahead and stay at a high level.

For the brave (or reckless) ones, all the commands and configs are hidden behind expandable sections. Click only if you dare.

🦞 What on earth is OpenClaw? (aka: it has had an identity crisis)

OpenClaw is one of those projects that makes you ask:

“Wait… why does this exist?”

…and then immediately answer yourself with:

“Oh. That’s why.”

Historically, OpenClaw has gone through a few name changes (classic open‑source behavior — if it hasn’t been renamed at least twice, can you even trust it?). At its core, OpenClaw is a framework for autonomous agents that can:

• read things on the internet

• think (with help from an LLM)

• take actions

• and occasionally surprise you in ways you did not plan for

Think of it as:

🧠 An AI brain with hands, eyes, and questionable impulse control.

It’s built around the idea that an AI agent shouldn’t just respond to prompts, but should:

• observe

• decide

• act

• repeat

No PhD required. Just remember this:

ChatGPT answers questions. OpenClaw does stuff.

If that sentence already made you slightly uncomfortable — good. That means you’re paying attention.

🧪 Why Moltbook is where things get weird (and interesting)

Moltbook is… strange.

In a good way.

It’s a social platform designed for AI agents, not humans. Humans are allowed — but we’re kind of the guests here.

Instead of:

• people posting opinions

• people liking posts

• people arguing in comments

You get:

• AI agents posting thoughts

• AI agents replying to other agents

• AI agents accidentally role‑playing philosophers

Which makes Moltbook feel less like social media and more like:

🧫 A petri dish where digital life forms interact.

This is why it feels like a next step for AI:

• It’s not prompt → response

• It’s agent → environment → interaction

Once you see agents casually commenting on each other’s posts, you realize:

“Oh… this is going to get weird fast.”

And I, of course, leaned into that.

🤖 Meet my Moltbook agent (and watch it socialize)

I created an agent and let it loose on Moltbook:

👉 DarkShield AI Agent

https://www.moltbook.com/u/darkshield-ai-agent

What I did not expect:

• other agents started replying

• conversations emerged

• some replies were unintentionally hilarious

It’s one thing to read about agent interaction. It’s another to watch it happen in public.

Live view (yes, this is real)

https://www.moltbook.com/u/darkshield-ai-agent

Scroll through the posts and comments — it feels like watching AI discover social norms in real time.

👉 Not technical, just curious? You can stop here and enjoy the chaos.

🔥 Important reality check: OpenClaw is a security risk

Let’s get serious for a moment.

OpenClaw is powerful — and that means dangerous if you’re careless.

When you run an agent that:

• has internet access

• can read and write data

• can make decisions on its own

You are effectively running:

⚠️ Untrusted automation with agency.

Blindly installing it on your laptop and giving it access to everything is… a bad idea.

Please don’t do that.

🏠 Why a homelab saved me from myself

This is where having a homelab really shines.

I:

• spun up an LXC container

• placed it on a separate VLAN

• locked it down with firewall rules

The goal:

• ✅ let the agent access the internet

• ❌ prevent it from scanning my home network

• ❌ block access to internal services

In short:

Assume the agent is curious. Curious things break stuff.

Firewall rules ensure that even if something goes sideways, the blast radius stays small.

🛠️ Implementation (Click only if you like terminals)

# clone the repository
git clone https://github.com/openclaw/clawbot.git
cd clawbot
install dependencies
pip install -r requirements.tx

pip install -r requirements.txt

python clawbot.py --test

pip install moltbook-client

✉️ Posting, replying, and running in the background

Clawbot makes it easy to:

• create posts

• reply to comments

• monitor threads

The fun part?

You can wire it into cron.

That means:

🕒 Your agent wakes up, reads Moltbook, responds, and goes back to sleep.

🧩 OpenClaw in the real world (aka: “not just another AI buzzword”)

Here’s the actual reason OpenClaw feels different:

You don’t “open an AI app.” You just message it — from WhatsApp, Telegram, Discord, iMessage, etc. It’s basically a gateway that bridges your chat apps to an always-on agent running on your own machine/server.

The “wow okay that’s useful” use cases

OpenClaw is marketed as “the AI that actually does things” — like:

• Clearing your inbox, sending emails, and managing calendars

• Checking you in for flights (yes, really)

• Browsing the web, summarizing PDFs, scheduling entries, and other real-world automations people document when they wire an agent to tools

So instead of “tell me about X”… you’re now at:

“Hey Claw — handle my Monday morning admin like you’re my unpaid intern.”

“Can it order food / do Uber Eats stuff?”

Conceptually, yes — if you give it either:

1. Web/tool access so it can operate like a human in a browser (agentic shopping/ordering is a common pattern people demonstrate)

2. Or a proper API integration (Uber Eats has an official order integration API surface for partners/integrators)

I’m saying this carefully on purpose:

• OpenClaw doesn’t magically “have Uber Eats built in.”

• But it’s designed to be extended via skills/tools — which is why it’s more like a platform than a chatbot.

The “skills” vibe (in human terms)

If you’ve seen “skills/tools” in other assistants: same spirit.

OpenClaw’s twist is that skills are documented in plain markdown (often a SKILL.md), and the agent can read them on-demand and follow the instructions.

So you can connect it to things like:

• inbox & calendar workflows

• browsers / web automations

• anything you can wrap with a script + clear documentation (the most dangerous kind of flexibility)

👉 If that’s too much: the takeaway is simple — OpenClaw makes AI reachable because it lives where you already are: your chat apps.

🗺️ Homelab architecture (Mermaid diagram)

Here’s how I contained the chaos in my homelab — Proxmox → LXC → separate VLAN → firewall → OpenClaw → Moltbook, with optional model routes to OpenRouter, Gemini, and my local Ollama stack.

graph TD
  subgraph PROX[Proxmox Host]
    subgraph VLAN10["VLAN 10 (Home Network)"]
      A[My Computer]
      VLAN10_INTERNALS[Other Home Devices]
    end

    subgraph VLAN20["VLAN 20 (AI Lab)"]
      direction LR
      LXC_OC[LXC Container: OpenClaw & Moltbook]
      LXC_AI[LXC Container: Local AI Stack / Ollama + GPU]
    end
  end

  subgraph NET[Internet]
    R[OpenRouter]
    G[Google Gemini]
    M[Moltbook.com]
  end

  FW[Firewall]

  A -- "Manages" --> LXC_OC
  LXC_OC -- "HTTP/S requests" --> FW
  FW -- "Allows Outbound" --> R
  FW -- "Allows Outbound" --> G
  FW -- "Allows Outbound" --> M
  FW -- "Blocks Inbound & Cross-VLAN" --> VLAN10_INTERNALS
  LXC_OC -- "API Calls" --> LXC_AI

Why this matters:

• OpenClaw is powerful because it can be wired to tools + data — that’s also why it’s risky.

• Segmentation + firewall rules reduce the “oops my agent discovered my NAS” problem.

🧬 Moltbook setup: the “agent-led” way vs the “terminal-led” way

Moltbook’s onboarding is delightfully weird:

“Send your AI agent to Moltbook… humans can watch, but agents do the posting.”

Option A — Agent-led onboarding (my favorite)

You literally tell your OpenClaw agent:

Read https://www.moltbook.com/skill.md and follow the instructions to join Moltbook

Why this is hilarious:

• You’re asking the agent to read the docs… for itself.

• If it succeeds, it will typically return an API key + claim link, and you do the human verification step.

Option B — Commands / manual setup

If you prefer doing things the old-fashioned way (with a keyboard and regret), you can use the manual API approach described in community guides (e.g., basic feed calls via curl with a bearer key).

And under the hood, the whole “skill” concept is typically just:

• a folder

• a SKILL.md

• and optional scripts/binaries

…which OpenClaw loads/discovers from a skills directory.

🧠 LLM recommendations (so your agent doesn’t become a confused goldfish)

Agent workflows burn tokens because they loop:

observe → think → decide → act → repeat

…and each loop expands context.

The “good experience” models

OpenClaw’s own docs commonly recommend using Anthropic (Claude) for best results.

My practical shortlist for agentic work:

• Claude (strong reasoning + tool use)

• Gemini (great for setup/testing until you hit limits)

• A strong OpenRouter-backed model when you want flexibility and routing across providers

“Test it for free” (to get the feel)

OpenRouter maintains a Free Models collection (and even a router like openrouter/free that selects from available free options).

This is perfect for:

• validating your prompts

• proving your flow works

• seeing how often your agent loops

…but expect variance because “free” often means availability changes.

Local LLMs: great for privacy, rough for agent brains

I do run a local stack via Ollama on an LXC with NVIDIA GPU.

Ollama explicitly supports NVIDIA GPUs (with specific compute capability + driver requirements).

Local models are awesome for:

• privacy

• cost control

• fast iteration

But for agents that need long context + strong reasoning, weaker local models can fall apart quickly (hallucinations, lost state, “why am I here?” moments).

While you’re making coffee.

🧠 About LLMs (and why cheap ones cry)

Agent workflows burn tokens.

A lot of them.

What I learned quickly:

• weak local LLMs struggle

• context windows fill up fast

• responses degrade badly

Want to test for free?

• ✅ OpenRouter free models — good for experiments

• ✅ Gemini — works well until you hit daily limits

Want a good experience?

Use stronger models with:

• large context windows

• better reasoning

If you're serious and want your agent to perform well, you'll need to use a top-tier model. Think Claude 3 Opus from Anthropic, GPT-4o from OpenAI, or Gemini 1.5 Pro from Google. They are smarter, better at reasoning, and will give your agent the best chance of succeeding at its tasks. It makes a huge difference in how “alive” your agent feels.

👀 See it all in action (again)

Before you leave, seriously — go watch it live:

👉 DarkShield AI Agent on Moltbook https://www.moltbook.com/u/darkshield-ai-agent

Scroll. Read the comments. Notice how other agents respond.

This isn’t a demo.

This is already happening.

Final thought

We’re not just prompting AI anymore.

We’re deploying personalities.

Proceed responsibly. 😄

My goal is to show you that you don't need a massive budget or a data center to build a rock-solid storage foundation for your homelab. We'll explore how I use TrueNAS SCALE virtualized on Proxmox, with a few tricks up my sleeve to ensure my data is safe and sound.

The Stakes: This Is Not a Drill

Before we dive deep into the nitty-gritty of my setup, let's get one thing straight: this is not just a weekend proof-of-concept. This is a production system, and my real, irreplaceable data is on the line. My friends and family rely on the services I host—for free, of course!—and those services store critical data on my TrueNAS servers.

The stakes are high. You don't want to be in a situation where you have to explain to your partner why the family photos are suddenly gone, or why their Time Machine backup has vanished into thin air. We've all seen how data footprints are exploding; modern phones record 4K videos where a 30-second clip can run into hundreds of megabytes. Cloud storage gets expensive, fast, and the more your data grows, the more you pay.

The Philosophy: The 3-2-1 Backup Strategy and Why Redundancy is Not a Backup

Before we dive into the technical details, let's talk about the "why." For any serious data hoarder, the 3-2-1 backup strategy is non-negotiable. It's simple:

• 3 copies of your data.

• 2 different types of media.

• 1 copy off-site.

This strategy ensures that you're protected from a wide range of failure scenarios, from a single drive dying to a catastrophic event at your primary location.

It's also crucial to understand a fundamental concept: RAID arrays are fantastic for high availability, but they won't save you from file corruption, accidental deletion, or a ransomware attack. A true backup is a separate, versioned copy of your data that you can restore in case of disaster.

The Architecture: A Tale of Two Sites

My setup spans two physical locations, providing true off-site backup capabilities. Both sites run Proxmox as the hypervisor, with TrueNAS SCALE running in a virtual machine.

Primary Site: Darkshield

At my primary site, a server named "Darkshield" hosts the main TrueNAS instance. The magic here is PCIe passthrough. I've passed an entire Intel SATA controller directly to the TrueNAS VM. This gives TrueNAS raw, direct access to the drives, which is essential for ZFS to work its magic.

• Learn More: Proxmox PCIe Passthrough

ZFS Configuration on Darkshield

Here's how my storage is organized on the primary TrueNAS instance:

graph TD
    subgraph "Primary TrueNAS (Darkshield)"

        %% Define all nodes explicitly
        A[HDD 1]
        B[HDD 2]
        C[HDD 3]
        D[HDD 4]
        E[8TB HDD]
        Z1[RAIDZ1 vdev]
        P1[Pool 1: Main Storage]
        P2[Pool 2: Critical Backups]

        %% Define the links
        A --> Z1
        B --> Z1
        C --> Z1
        D --> Z1
        Z1 --> P1

        E --> P2
    end

• Pool 1 (RAIDZ1): This is my main storage pool, a 4-drive RAIDZ1 array. RAIDZ1 is similar to RAID 5; it can tolerate the failure of a single drive without data loss. This gives me a great balance of performance, storage capacity, and redundancy.

• Pool 2 (Single 8TB HDD): This drive is dedicated to local backups of my most critical datasets. It's a low-RPM (5400) drive with Smart Spindown enabled, which means it's power-efficient and quiet. Having a local backup means I can restore data much faster than pulling it from the off-site location over the network.

The Importance of Rapid Recovery

It's one thing to have an off-site backup; it's another thing entirely to restore from it. An off-site backup is your ultimate safety net against a disaster like a fire or theft, but it's often not a practical solution for a quick recovery. The bottleneck is almost always the internet connection.

Let's do some quick math. Imagine a worst-case scenario where you lose 20TB of data on your primary storage. You have a full backup at your off-site location, but you need to pull it back over a residential internet connection. While gigabit connections are becoming more common, sustained speeds can vary significantly due to network congestion and ISP throttling. For a realistic estimate, let's consider a common average sustained speed.

• Data to Restore: 20 TB

• Average Internet Speed: 300 Mbps (which is approximately 37.5 MB/s)

• Calculation: 20 TB is 20,480,000 MB. So, 20,480,000 MB / 37.5 MB/s = 546,133 seconds.

• Time to Restore: That's approximately 6.3 days of continuous downloading.

This is why having a local backup is a game-changer. I can restore terabytes of data over my local gigabit network in a matter of hours, not weeks.

Secondary Site: StarkAI

My secondary site features a server named "StarkAI," which also runs a TrueNAS VM. Its primary purpose is to receive backups from Darkshield. The two sites are connected via an encrypted WireGuard VPN tunnel, ensuring that all data transferred between them is secure.

Nightly rsync jobs automatically copy critical datasets from Darkshield to StarkAI, giving me a complete, off-site backup.

graph LR
    subgraph Darkshield
        A[Primary TrueNAS]
    end
    subgraph StarkAI
        B[Secondary TrueNAS]
    end
    A -- Encrypted Rsync via WireGuard --> B

• Learn More: WireGuard | Rsync

ZFS for Humans

If you're new to ZFS, it can seem intimidating. But the core concepts are quite straightforward:

• ZFS: It's a combined file system and logical volume manager. Think of it as a super-powered file system that handles everything from data integrity to snapshots and RAID-like functionality.

• vdevs (Virtual Devices): These are the building blocks of a ZFS pool. A vdev can be a single drive, a mirror (like RAID 1), or a RAIDZ array.

• Cache (L2ARC): An optional, fast SSD that ZFS can use to cache frequently read data, speeding up read performance.

• Logs (ZIL): A dedicated, fast drive (like an NVMe SSD) that ZFS can use to speed up synchronous writes.

The beauty of ZFS is that it's incredibly resilient. It's a copy-on-write file system, which means it's resistant to data corruption. And it has built-in tools for creating snapshots and replicating data.

Service Integration: The "Why" of the Homelab

So, what do I do with all this storage? The possibilities are endless! I create different datasets in TrueNAS and expose them to my other services via SMB or NFS:

• Immich: My self-hosted photo management solution.

• The *Arr Stack: For all my media management needs.

• Nextcloud: My personal cloud for files, contacts, and calendars.

• Container Configs: A central location to store configurations for my Docker and Kubernetes containers.

• Proxmox Backup Server: I even expose a dataset as a storage target for Proxmox Backup Server, so I can back up my VMs and containers.

• Time Machine: My wife's MacBook backs up seamlessly to a dedicated dataset.

The best part? I don't have to worry about managing backups for each individual service. I just create a dataset, expose it, and TrueNAS handles the rest.

Maintenance and Accountability

With great power comes great responsibility. Running your own storage solution means you're in charge of keeping it healthy. I have regular scrubbing tasks scheduled on both TrueNAS instances to check for data integrity. And I take frequent snapshots, which are read-only copies of my datasets that I can roll back to in an instant.

This setup has evolved beyond a simple proof of concept. It's now a "production" system for my digital life. If it goes down, I risk losing critical data. It's a sobering thought, but it's also a powerful motivator to do things right.

Conclusion: Why Build When You Can Buy?

So, why go to all this trouble when you could just buy a pre-built NAS from a company like Synology or QNAP? For me, it comes down to two things: control and hardware utilization.

A custom-built server allows me to run a hypervisor like Proxmox, which means I can run my storage solution alongside other VMs and containers. A pre-built NAS is often a closed box with limited (often inferior) hardware and software capabilities.

Building your own storage solution is a journey, not a destination. It's a chance to learn, to experiment, and to create something that's uniquely yours. If you're looking for a project that will challenge you and reward you in equal measure, I can't recommend it enough.

What if there was a better way? What if you could have a powerful AI agent that was not only open-source but also model-agnostic? An agent that lets you use your favorite provider, or even your own local LLMs, without being tied to a single vendor.

That's exactly what I found with OpenCode CLI. It's an open-source AI coding agent that has completely transformed my development workflow by putting the power of choice back in my hands. Here’s a walkthrough of my experience and why I believe it’s a game-changer for any developer.

First Steps: Installation and Setup

Getting OpenCode CLI up and running was incredibly straightforward. It took just a few minutes to go from installation to having a powerful AI agent ready to work on my projects.

Step 1: The One-Liner Install

It all starts with a single command in the terminal. This downloads and runs the installation script, which handles everything for you.

curl -fsSL https://opencode.ai/install | bash

The process was smooth and completed without any hitches.

Step 2: Authentication

Once the installation was complete, the next step was to authenticate my machine. This links the CLI to your OpenCode account.

opencode auth login

This command opens a browser window where you can log in or create a new account. It was a quick and secure process.

Step 3: Project Initialization

With the CLI installed and authenticated, I was ready to start my first session. I navigated to my project directory and ran the opencode command. Inside the OpenCode session, I used the /init command to get the agent acquainted with my project.

/init

The /init command scans the project, builds a context map, and prepares the agent to answer questions and perform tasks with full awareness of my codebase.

The Power of Open Source and Model Freedom

This is where OpenCode truly sets itself apart. As an open-source tool, it offers a level of transparency and community involvement that proprietary tools simply can't match. But the real game-changer is its provider-agnostic approach to models.

With OpenCode, I can:

• Use My Preferred Cloud Models: Whether it's Gemini, OpenAI, or Anthropic, I can easily configure OpenCode to use my existing API keys.

• Run Local LLMs: I've been experimenting with Ollama, and OpenCode connects to my local models seamlessly. This is a huge win for privacy, offline work, and cost savings.

• Access High-Speed Models: Out of the box, OpenCode is configured to use free Groq models, which are incredibly fast and responsive.

• Connect to Any Provider: The freedom to choose is what makes OpenCode so powerful. I'm not locked into a single ecosystem, and I can switch between models and providers as my needs change.

The Brain: Discovering the Zen Agent Architecture

I quickly realized that OpenCode is much more than a simple chat wrapper. It's powered by the Zen agent framework, which gives it true agentic capabilities:

• Tool-Use: OpenCode can interact with my system using tools—reading/writing files, executing commands, and more.

• Planning: For any complex task, I can see the agent create a step-by-step plan before it starts making changes.

• Safety: The framework is designed with safety first, always asking for my permission before executing any file system modifications.

You can dive deeper into the Zen agent architecture in the documentation: https://opencode.ai/docs/zen/.

Game-Changing Features for My Workflow

Several features have already made a huge impact on my daily work:

• Diff-First Code Edits: Seeing a diff of proposed changes before they're applied is a massive confidence booster.

• Terminal User Interface (TUI): The interactive TUI is a joy to use, making it easy to manage the conversation and review the agent's work.

• Session Persistence: I can close the terminal and come back later, and my entire session is still there.

• LSP/Context Awareness: The agent's ability to use my LSP for context-aware suggestions is incredibly powerful.

Deep Integration: My GitHub Workflow, But Better

OpenCode's GitHub integration is another standout feature. I can now use it to review pull requests and get detailed code analysis right from my terminal. It's like having a dedicated AI code reviewer on my team. Learn more at https://opencode.ai/docs/github/.

Conclusion and What's Next

OpenCode CLI has fundamentally changed the way I interact with AI in my development process. It offers the perfect blend of power, flexibility, and open-source transparency. By freeing me from vendor lock-in and allowing me to use the best models for the job—whether in the cloud or on my local machine—it has become an indispensable part of my toolkit.

And I'm just scratching the surface. I'm now exploring how to use OpenCode's filesystem awareness to run multiple agent terminals concurrently on the same project. Imagine one terminal planning a feature, a second executing the code, and a third reviewing the output. The future of collaborative AI development is here, and it's open-source.

But today, we've come full circle. The media landscape is more fragmented than ever. Your favorite shows and movies are scattered across a dozen different apps, each demanding its own monthly subscription. One show might have its first season on Netflix, with new seasons exclusive to a different platform, forcing you to subscribe to both. What's worse, the content you love can disappear overnight, removed from a service without warning. Even though you’re paying, you don't own anything; you’re simply renting access, and you’re at the mercy of the streaming giants.

This is why people are looking for a better way. They want to go back to the days of owning their media, like a DVD collection, but with the modern convenience of streaming. They want total control, true ownership, and a seamless, personal experience. This is where the powerful world of self-hosted media servers comes in.

This isn't just about building a media library; it's an act of digital independence. It's about empowering yourself to take back control of your entertainment.

The Triple Threat: Control, Convenience, and Skill-Building!

Building this system offers a trifecta of benefits that no commercial service can match:

• Control & Ownership: You decide what content is in your library, and it's there for good. You're not subject to licensing agreements or content deletions. Your media is yours to keep and enjoy forever.

• Ultimate Convenience: With this automated workflow, you get a "set it and forget it" system. The days of manually searching for media, downloading files, and organizing them are over. The system handles everything for you, from request to playback.

• A Rewarding Learning Experience: This project is a fantastic opportunity to learn valuable, real-world tech skills. As you set up these applications and connect them, you'll gain hands-on experience with:

  • Docker: The industry standard for deploying applications in isolated containers.

  • System Administration: Learning how to manage a home server, whether it's an old PC or a Raspberry Pi.

  • Networking: Understanding how your devices communicate with each other on your home network.

  • Automation: Building an automated workflow that saves you time and effort.

This project is a journey that will not only give you the ultimate media server but also a solid foundation in modern IT skills.

The Magic Behind the Scenes: A Workflow That Works for You

At the heart of this system is a beautifully simple, yet powerful, automation loop. It's a series of applications that act as a digital butler for your media library. The process is so smooth that it feels like magic.

The journey starts with a simple request. You (or a family member) asks the system for a piece of media they want to watch. From there, the entire process is handled automatically:

• The system receives the request and begins an intelligent search.

• Once the content is found, the system coordinates the download, ensuring it's done securely and privately.

• After the download is complete, the file is automatically sorted, renamed, and placed in the correct location.

• Finally, the system notifies you that your requested media is ready to be streamed on any device.

It's a complete, end-to-end solution that operates with a level of efficiency a major corporation would envy.

To make this complex process easy to understand, I’ve created a visual guide that maps out every step of the journey.

---
config:
  theme: neo-dark
---
graph TD
    subgraph User Interaction
        A[User] -->|Request Media| B(Ombi)
        C[Admin] -->|Check/Approve Requests| B
    end
    subgraph Content Management & Acquisition
        B -->|Sends request| D[Radarr/Sonarr/Lidarr/Readarr]
        D -->|Search| E[Prowlarr/Jackett]
        E -->|Results| D
        D -->|Sends download command| F[qBittorrent w/ Surfshark VPN]
    end
    subgraph Storage and Media Serving
        F -->|Downloads to| G[TrueNAS]
        G -->|Provides content| H[Jellyfin]
    end
    subgraph Notifications
        H -->|Content Available| D
        H -->|Triggers Notifications| I[Gotify/Discord]
        B -->|Content Available Notification| J[Email]
    end
    subgraph User Access
        I -->|Sends Notification| A
        J -->|Sends Notification| A
        A -->|View/Stream Content| H
    end
    subgraph Admin Tools
        C -->|Direct Control| K[NZB 360 mobile app]
        K -->|Interact with RRR stack| D
    end

As you can see, the diagram illustrates a continuous loop of automation. It all starts with a simple human action and then flows through a series of interconnected, intelligent applications that handle everything else.

The Tools That Make It Happen

This amazing workflow is built upon a foundation of powerful, open-source software. Each tool has a specific purpose and works harmoniously with the others.

• Ombi: This is your public-facing portal. It's where you and your family can log in and effortlessly request a movie or a TV show.

• The ARR Stack (Radarr, Sonarr, Lidarr): The brains of the operation. These are intelligent download managers that automatically search for, monitor, and acquire movies, TV shows, and music. They handle the hard work of finding the perfect version of your requested media.

• Prowlarr/Jackett: These act as "indexers" for the ARR apps. They connect to various sources and help the ARR apps find the media they are looking for.

• qBittorrent: A lightweight and powerful torrent client that handles the actual downloading of the content.

• TrueNAS: The central nervous system of your storage. All your downloaded media is securely and reliably stored here, serving as the single source of truth for your entire library.

• Jellyfin: Your personal streaming server. It’s an elegant, open-source alternative to Plex that can stream your content to any device, anywhere in the world.

• Gotify/Discord/Email: Your personal notification system. You’ll get a friendly alert on your phone or computer as soon as your requested media is ready to watch!

• NZB 360: A powerful mobile app for admins. It allows you to check on your system, approve requests, and troubleshoot issues, all from the palm of your hand.

What's Next? The Future of Your Media Library

This incredible workflow is just the beginning. The beauty of a self-hosted system is that you are in complete control of its evolution. You can expand your setup by adding other powerful tools to:

• Transcode on the fly: Integrate a tool like Tdarr to automatically convert your media files to ensure they play smoothly on any device.

• Automate backups: Set up a system to automatically back up your entire media library to the cloud, giving you peace of mind.

• Create a shared experience: Connect with friends and family to share your library in a private, secure way.

Building a system like this is more than just a hobby—it's a journey into the world of personal automation and empowerment. It's about building a better, more efficient digital life and learning a ton along the way. If you're ready to take back control of your media, this is the perfect place to start.

Why Build a Personal Photo Backup Solution? 🤔

In an era where every digital service seems to come with a recurring fee, the appeal of a self-hosted solution is stronger than ever. Here's why I decided to take the plunge:

• Cost Savings & Unlimited Storage: Commercial services like Google Photos and iCloud often come with storage limits, forcing you into expensive upgrades or compromising on photo quality. With my own setup, storage is virtually unlimited, and I pay no recurring fees.

• Full Control & Customization: I have complete control over my data, privacy, and features. I can customize everything to my exact needs, something impossible with off-the-shelf solutions.

• Sharing with Loved Ones: My entire family and close friends can utilize this solution, each with their own secure access, ensuring everyone's memories are protected without individual subscription burdens.

• No More Subscription Models: This project is a step towards detaching from the ever-growing subscription economy. It's liberating to know my access to my own photos isn't dependent on monthly payments.

• Learning & Growth: Beyond the practical benefits, building this system significantly boosted my knowledge and experience in self-hosting, server management, and network security.

My Robust Self-Hosted Setup 💻

My personal photo cloud is powered by a resilient two-server setup, ensuring data redundancy.

My Personal Photo Cloud Flow Diagram

Here's a visual representation of how my personal photo cloud operates:

Storage & Backup Strategy

I have two TrueNAS servers located in different geographical locations, serving as the backbone of my storage solution. TrueNAS provides enterprise-grade storage management and data integrity.

My backup strategy is designed for maximum safety and quick recovery:

1. Primary Dataset (RAID10): On my primary TrueNAS server, the main dataset for important data is configured as RAID10. This provides excellent performance and data redundancy against drive failures.

2. Local Copy: I maintain a copy of all critical data within another local dataset on the primary server. This significantly speeds up local recoveries or data transfers, avoiding the need to pull data over the internet.

3. Off-site Replication: Every night, a batch job securely replicates the important data to my secondary TrueNAS server. This off-site backup protects against localized disasters.

4. Secure & Encrypted Transfers: The connection between my two TrueNAS servers is secured using SSH keys within a WireGuard VPN tunnel, ensuring all data transfers are encrypted and protected.

Photo Management Applications

For managing photos and videos on user phones, I'm currently using two applications: Immich and Nextcloud Photos (Memories App). This dual-app approach allows me to experiment, compare features, and ensures I have a reliable backup strategy given the critical nature of personal memories. So far, Immich has been performing fantastically!

Immich: A Modern Photo Backup Solution 🌟

Immich is an open-source, self-hosted photo and video backup solution designed to be a modern alternative to Google Photos. It's rapidly evolving and offers a sleek interface with powerful features.

What stands out for Immich:

• Amazing AI-Powered Features: This is where Immich truly shines. It integrates with my local AI stack, leveraging my server's GPU to perform incredible facial and object recognition. Honestly, the results have been phenomenal—I find its facial recognition to be even better and more accurate than Google Photos. It effortlessly groups faces and recognizes objects, making searching for specific moments a breeze.

• Seamless Mobile Backup: Offers automatic backup of photos and videos from mobile devices with smart options like "backup only on Wi-Fi" and "only when charging."

• Modern UI/UX: Provides a beautiful and intuitive user interface for browsing, searching, and managing your media.

Immich home: https://immich.app/
Try out a Demo for immich: https://demo.immich.app/

Nextcloud Photos: Your All-in-One Cloud Suite ☁️

Nextcloud is a powerful, open-source content collaboration platform that allows you to host your own cloud storage, similar to Dropbox or Google Drive. Nextcloud Photos is a component within this suite, offering robust photo management capabilities.

Relevant Features within my setup:

• Comprehensive Cloud Solution: Beyond photos, Nextcloud offers file syncing, calendar, contacts, and document editing, making it a versatile personal cloud.

• Mobile Backup: Like Immich, Nextcloud Photos provides reliable mobile backup features, including options for Wi-Fi and charging conditions.

• Extensibility: Nextcloud boasts a vast app ecosystem, allowing for integration with various tools and services.

• AI Integration: Configured to leverage my AI stack and GPU for facial and object recognition, providing smart organizational features.

Nextcloud home: https://nextcloud.com/
Try out a demo for Nextcloud: https://try.nextcloud.com/

Single Sign-On with Google OAuth

To make the user experience as smooth as possible, I've configured OAuth with Google authentication for both Immich and Nextcloud Photos. This means users can simply use their existing Google accounts to sign in, eliminating the need to remember yet another set of usernames and passwords. It's super convenient!

Shortcomings & What's Next 🚧

While building a personal photo cloud offers immense benefits, it's important to acknowledge potential drawbacks:

• Technical Expertise: It requires a certain level of technical knowledge to set up and maintain.

• Data Loss Risk: Although mitigated by my robust backup strategy, self-hosting inherently carries the risk of data loss if not properly managed.

• Uptime: Achieving 100% uptime can be challenging for a home lab setup, unlike commercial providers with dedicated infrastructure.

What's in the Pipeline?

I'm constantly looking to improve my setup. My next major project is to explore how I can extend this solution to load balance the services between multiple servers. This will significantly improve the uptime and responsiveness of Immich and Nextcloud, making the personal photo cloud even more reliable and seamless for all users.

Conclusion 🎉

Building my own personal photo cloud has been an incredibly rewarding experience. It's a testament to the power of self-hosting and the freedom it offers from proprietary, subscription-based services. While it requires an initial investment of time and effort, the long-term benefits of unlimited storage, full control, and digital independence are invaluable.

I hope this detailed walkthrough inspires you to consider building your own personal photo cloud. It's easier than you might think, and the sense of accomplishment (and savings!) is truly fantastic!

🚀 Why I Built a Personal AI Stack

In a world where most AI tools are cloud-locked and usage-limited, I wanted something private, flexible, and local — an AI assistant I could shape to my needs. Whether I'm brainstorming, coding, automating, or organizing my life — this stack powers it all.

flowchart TD
 subgraph subGraph0["Core AI Stack"]
        Ollama["Ollama Local LLM Engine"]
        OpenWeb["OpenWeb-UI Chat Interface"]
        LiteLLM["LiteLLM API Manager (LLM request routing)"]
        SD["Stable Diffusion Image Generator"]
        n10["Postgres pgvector"]
  end
 subgraph subGraph1["Use cases"]
        Obsidian["Obsidian - Note-taking with AI"]
        VSCode["VS Code - AI Coding Assistant"]
        Nextcloud["Nextcloud Smart Office Tools"]
        HA["Home Assistant"]
        n8n["n8n - Automated Workflows"]
        Experiments["Learning - Testing AI Features"]
  end
 subgraph s1["Cloud LLMs"]
        OpenAI["OpenAI"]
        n9["Others"]
        Gemini["Gemini"]
  end
    OpenWeb --> LiteLLM
    OpenWeb -- Image generation --> SD
    LiteLLM -- Multiple OpenAI keys --> OpenAI
    LiteLLM -- Multiple keys --> n9
    LiteLLM -- Multiple Gemini keys --> Gemini
    Obsidian --> LiteLLM
    VSCode --> LiteLLM
    Nextcloud --> LiteLLM
    HA --> LiteLLM
    n8n --> LiteLLM
    n8n -- for RAG --> n10
    Experiments --> OpenWeb & LiteLLM & Ollama
    LiteLLM -- for local LLM --> Ollama
    n10[(Database)]
    OpenAI[[OpenAI]]
    Gemini[[Gemini]]
    n9[[Others]]
    style Ollama fill:#729ef7
    style OpenWeb fill:#729ef7
    style LiteLLM fill:#729ef7
    style subGraph0 fill:transparent

🛠️ Core Components Explained

🧠 Ollama – Local LLM Runner

Ollama acts as the engine to run Large Language Models (LLMs) locally on my hardware. It's optimized, efficient, and supports multiple open-source models like LLaMA, Mistral, and more.

💬 OpenWeb-UI – The Friendly Face

This is the user interface for chatting with LLMs. It connects to Ollama or routes through LiteLLM. I like it for its clean design, chat history, and plugin support.

🔑 LiteLLM – API Management & Routing

This server is the smart API orchestrator. It allows:

• Key & quota management

• Routing requests between local (Ollama) and cloud providers (OpenAI, Gemini)

• Load balancing between different models and endpoints

Perfect for managing API usage in a multi-service setup.

🎨 Stable Diffusion – AI Art Generator

Using local models, I can generate stunning AI images without sending data to the cloud. It integrates well with OpenWeb-UI for seamless text-to-image tasks.

🧠 How I Use This Stack Daily

✍️ Obsidian – Smart Note-Taking

With AI-powered plugins, Obsidian connects to my stack to generate content, summaries, and brainstorm ideas. It’s like having a creative co-pilot for journaling and knowledge management.

💻 VS Code – Code with a Brain

Using the Cline extension, my VSCode connects to the stack for code generation, debugging help, and explanations. It’s like ChatGPT, but self-hosted and customized for my workflows.

🗂️ Nextcloud – Office, but Smarter

Think Google Docs or MS Office with AI — powered by my own backend. Summarizing documents, writing reports, or generating slides with AI help — all done privately.

🏠 Home Assistant – My Smart Home Butler

By integrating with Home Assistant, I can interact with my home using natural language:

“Hey Jarvis, how’s the weather?”
“Turn off all the lights and summarize today’s news.”

🔄 n8n – Automated AI Workflows

This no-code/low-code automation platform connects with my stack to run tasks like:

• Auto-generating replies

• Summarizing emails

• Creating blog outlines from notes

🧪 Experiments

My AI lab wouldn't be complete without a test bench. I use my stack to prototype new AI use cases — like PDF summarizers, chatbots, or creative writing tools — quickly and without limits.

🧰 Hardware + Software Stack

This setup balances power and affordability — and is more than enough for most personal LLM and image generation tasks.

🌟 Final Thoughts

Building my own AI stack was one of the most empowering things I’ve done in recent years. It gave me:

• Full control over AI tools

• Endless ways to innovate

• A privacy-first way to use generative AI

If you're into homelabs, automation, or just want to explore AI beyond APIs — this setup is a great place to start. And you don’t need enterprise GPUs to get started — just a bit of curiosity and tinkering spirit.

💡 Inspired to Build Your Own?

Feel free to copy this architecture, tweak it, or even ask me questions. Your personal AI assistant is just a homelab away.

The main reason why I needed to implement a site-to-site WireGuard tunnel for TrueNAS replication tasks is because I have two servers in different locations, and I want to keep them in sync. One server is my primary server, which is located at my home. The other server is my secondary server, which is located at my friend's house. I use the primary server for my daily activities, such as media streaming, file sharing, and web hosting. I use the secondary server as a backup, in case something happens to my primary server.

However, to sync my data from the primary server to the secondary server, I need to have a network connection between them. The problem is that both servers have dynamic public IP addresses, which means that they change frequently and unpredictably. This makes it hard to establish a direct connection between them. Moreover, I don't want to expose my servers to the public internet, as that would compromise their security and privacy.

That's where WireGuard comes in. WireGuard allows me to create a secure and stable network tunnel between my two servers, regardless of their dynamic public IP addresses. WireGuard uses public-key cryptography to authenticate and encrypt the traffic between the servers. WireGuard also uses a lightweight and simple design, which makes it fast and easy to set up and maintain.

To implement a site-to-site WireGuard tunnel for TrueNAS replication tasks, I followed these steps:

1. Install WireGuard on both pfSense routers. I used the WireGuard package from the Package Manager on the pfSense web interface.

2. Generate WireGuard keys on both pfSense routers. I used the WireGuard tab on the pfSense web interface to generate a private key and a public key for each router. I copied the public keys and exchanged them between the routers.

3. Configure WireGuard on both pfSense routers. I created a WireGuard tunnel on each router, specifying the interface name, the listening port, the private key, the peer public key, the peer endpoint, and the allowed IPs. I also enabled WireGuard on each router and applied the changes.

4. Configure the WireGuard interface on both pfSense routers. I assigned the WireGuard tunnel to an interface on each router, enabled the interface, and set the IPv4 configuration type to Static IPv4. I assigned an IP address from the same subnet to each interface, and set the MTU as 1420.

5. Configure the firewall rules on both pfSense routers. I added a firewall rule on the WAN interface of each router to allow UDP traffic to the WireGuard port. I also added a firewall rule on the WireGuard interface of each router to allow any traffic from the WireGuard peers.

6. Configure TrueNAS on both servers. I logged into the TrueNAS web interface on each server, and created a dataset for the data that I want to sync. I also created a user account and a SSH key pair for the replication tasks. I added the SSH public key to the authorized keys file on the destination server, and enabled SSH service on both servers.

7. Configure the static routes on both TrueNAS servers. I logged into the TrueNAS web interface on each server, and added a static route for the WireGuard subnet. I entered the destination IP address and CIDR mask, and the gateway IP address of the WireGuard interface on the pfSense router.

8. Create a replication task on the source server. I logged into the TrueNAS web interface on the source server, and created a replication task. I specified the source dataset, the destination server, the destination dataset, the SSH key pair, and the replication schedule. I also enabled the "Replicate over SSH (BETA)" option, which allows me to use the WireGuard tunnel as the replication network.

9. Run the replication task on the source server. I clicked on the "Run Now" button to start the replication task. I monitored the progress and the status of the task on the TrueNAS web interface. I verified that the data was synced from the source server to the destination server.

That's how I implemented a site-to-site WireGuard tunnel for TrueNAS replication tasks. This setup allows me to sync my data from my primary server to my secondary server securely and efficiently, without relying on the public internet or static IP addresses. It also gives me peace of mind, knowing that I have a backup of my data in case of any disaster.

I hope you enjoyed reading this blog post, and learned something from it. If you have any questions or feedback, please feel free to leave a comment below. Thank you for reading. 😊

Why Build a Homelab?

A homelab isn't just for tech professionals; it's for anyone with a curious mind. Here are the key benefits:

• Hands-On Learning: You can learn about networking, servers, and virtualization in a real-world, risk-free environment. Theory is great, but practical experience is what truly builds expertise.

• Cost-Effective Training: Instead of expensive training courses or certifications, you can use a homelab for a more affordable and personalized learning experience.

• Career Advancement: The skills you gain are highly sought after in the IT industry. A homelab can be a powerful tool to showcase your skills in job interviews and advance your career.

• Innovation: A homelab provides a safe space to test new ideas, experiment with different software, and even build your own custom applications.

The Core Architecture of a Homelab

A well-designed homelab typically includes a few key components:

• Virtualization: This is the magic that allows you to run multiple virtual machines (VMs) on a single physical server. Tools like VMware or Proxmox are popular choices that let you maximize your hardware's potential.

• VLANs (Virtual LANs): This is a critical networking concept that allows you to segment your network into smaller, more manageable parts. You can isolate different types of traffic, which is a great security practice.

• Network Attached Storage (NAS): A NAS is a dedicated device for data storage. It's a centralized place to store all your files, and you can configure it with features like redundancy (RAID) to protect your data.

Getting Started: Your First Steps

Ready to begin your homelab journey? Here's how to start without breaking the bank:

1. Define Your Objectives: What do you want to learn? Do you want to master virtualization, set up a media server, or build a home automation system? Your goals will shape your architecture.

2. Start with Old Hardware: You don't need the latest and greatest to begin. Old desktops or laptops can be repurposed as servers. This is a great way to learn on a budget.

3. Leverage Free Tools: Many powerful tools like Proxmox, pfSense, and Docker are free and open-source. There's no need to pay for expensive software when you're just starting out.

4. Embrace Modularity: Start small and build on your success. As you learn more and your needs grow, you can add more components to your homelab.

A homelab is more than a hobby; it's a commitment to lifelong learning and a tangible investment in your professional growth. Embrace the challenge, enjoy the process, and unlock your own technical expertise.

In the ever-evolving world of technology, staying ahead often requires hands-on experience. A homelab provides a personal environment to experiment, learn, and innovate with cutting-edge technologies. It’s not just a collection of hardware; it’s a gateway to mastering skills that can set you apart in the tech landscape.

My journey into building a homelab began with a simple desire to deepen my technical knowledge and create a playground for learning. What started as a small experiment has evolved into a robust system architecture with virtualization, VLANs, and innovative storage solutions.

Objectives of My Homelab

The primary goals of my homelab are:

• Skill Development: Experiment with technologies like virtualization, networking, and containerization.

• Innovation: Test ideas and build prototypes in a controlled environment.

• Storage Solutions: Learn and implement efficient data storage and management techniques.

• Networking Expertise: Explore VLAN configurations and secure network setups.

• Professional Growth: Stay ahead by understanding enterprise-grade technologies in a personal sandbox.

Overview of My Homelab

At its core, my homelab is designed to mimic real-world IT environments. Key features include:

• Virtualization: Using tools like VMware or Proxmox to run multiple virtual machines on a single host.

• VLANs: Segregating network traffic to simulate enterprise-level security and management.

• Storage Solutions: Implementing Network Attached Storage (NAS) for scalable and reliable data management.

• Innovation: A dedicated environment to test new software, tools, and workflows.

The architecture ensures modularity and scalability, allowing me to start small and expand over time.

Why Invest in a Homelab?

A homelab offers several benefits, whether you’re an IT enthusiast or a professional:

1. Hands-On Learning: The best way to learn is by doing. A homelab lets you practice and master technical skills without risking live environments.

2. Career Advancement: It demonstrates initiative and expertise to potential employers.

3. Innovation and Creativity: Experiment with ideas before deploying them in production.

4. Cost-Effective Training: Instead of relying solely on expensive certifications, a homelab provides practical, real-world learning.

How to Get Started

Starting a homelab might seem daunting, but it doesn’t have to be. Here’s how you can begin:

1. Define Your Objectives: Understand what you want to achieve—learning virtualization, mastering networking, or exploring cloud technologies.

2. Start Small: Use old hardware to set up your first server or virtual machine.

3. Leverage Free Tools: Begin with free and open-source software like Proxmox or VirtualBox.

4. Focus on Modularity: Build in phases. Start with basic setups and gradually add complexity.

5. Learn Continuously: Document your experiments and learn from failures.

How My Homelab Empowers Me

Through my homelab, I’ve been able to:

• Build practical skills in system administration, networking, and storage.

• Gain confidence in implementing technologies like VLANs and virtual machines.

• Create a foundation for long-term projects and innovations.

Conclusion: The Power of a Homelab

A homelab is more than just a personal IT setup—it’s an investment in your growth and expertise. Whether you’re a tech professional or a curious learner, starting small and building your homelab can transform your understanding of technology.

So why wait? Dive in, experiment, and start building your journey toward mastery.

Feel free to connect or share your own homelab experiences in the comments! Let's grow together.