The 2026 Homelab Automation Stack: Moving Beyond Simple Containers

Reading time: ~18 minutes Audience: Homelab owners running 10+ containers who want their infrastructure to respond to events automatically — with AI-powered intelligence, not just cron jobs

Introduction: Why “Set and Forget” Is No Longer Enough

You deployed your first Docker container. Then ten more. You added Proxmox as your hypervisor, Nginx Proxy Manager for reverse proxy, and a handful of monitoring dashboards. Everything works — until it doesn’t. A disk fills up at 3 AM. A container crashes silently. A certificate expires. You discover these things when something breaks, not before.

The 2026 homelab has outgrown passive monitoring. Running a modern self-hosted stack means dozens of interconnected services, each with its own failure modes, update cadences, and resource requirements. Manual intervention doesn’t scale. What scales is event-driven automation — a system that detects anomalies, reasons about them, and acts without you reaching for an SSH client.

This guide assembles the three components that make that possible: n8n for workflow orchestration, Ollama for local AI intelligence, and Uptime Kuma for event-driven observability. Together they form a stack that watches your infrastructure, thinks about what it sees, and fixes what it can.

The 2026 Standard: Agentic Infrastructure

The term “agentic” has become shorthand for systems that don’t just report problems — they respond to them. In the homelab context, this means:

This isn’t science fiction. Every piece is available today as open-source, self-hosted software — and this guide shows you how to wire them together.

What Defines a 2026 Automation Stack?

From Static Containers to Event-Driven Systems

A traditional homelab runs containers defined in a docker-compose.yml file. They start, they serve, they (hopefully) stay running. This is static infrastructure — it does what you told it to do when you ran docker compose up -d, and nothing more.

An event-driven system adds a layer that says: when X happens, do Y. X could be a service going down, a disk hitting 90% utilization, a new CVE being published for one of your containers, or a backup job completing. Y could be sending a notification, restarting a container, running a cleanup script, or asking an LLM to summarize a log dump and suggest next steps.

The key architectural shift: your automation stack becomes a peer to your application stack, not a bolt-on. It gets its own Docker network, its own resource budget, and its own persistence.

The Three Pillars: Orchestration, Intelligence, Observability

Each pillar feeds the others: Uptime Kuma detects a service outage → fires a webhook to n8n → n8n queries Ollama for log analysis → n8n sends a contextual alert to Discord or Matrix. When it works, you receive a message that says: “Jellyfin is down. Probable cause: transcode directory full (97%). Action taken: cleared transcode cache, restarted container. Confirmed healthy.”

Pillar 1: Workflow Orchestration with n8n

Why n8n Beats Zapier and Make for Homelabs

n8n is a fair-code workflow automation platform that you self-host. It connects to hundreds of services through native nodes, supports custom JavaScript and Python execution, and runs entirely on your hardware. For homelab use, three factors make it the clear choice over cloud alternatives:

The on-prem nature is the killer feature for homelabs. n8n can reach services on 192.168.x.x addresses, talk to your Proxmox API, SSH into LXC containers, and read local files — none of which a cloud automation tool can do without exposing your network.

Docker Compose Setup for n8n

Create a dedicated directory for your automation stack and deploy n8n with PostgreSQL (recommended for production use) and Redis (for queue mode and performance):

# docker-compose.yml — n8n Automation Core
version: '3.8'

services:
  # PostgreSQL — n8n's database for workflow storage and execution state
  # Without this, n8n uses SQLite which is fine for testing but
  # chokes on concurrent workflow executions
  postgres:
    image: postgres:16-alpine
    container_name: n8n-postgres
    restart: unless-stopped
    environment:
      - POSTGRES_USER=${POSTGRES_USER:-n8n}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB:-n8n}
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - automation-net

  # Redis — enables queue mode for n8n
  # Without Redis, n8n processes workflows in-process. With Redis,
  # you get separate workers, retry queues, and better concurrency
  redis:
    image: redis:7-alpine
    container_name: n8n-redis
    restart: unless-stopped
    command: redis-server --appendonly yes
    volumes:
      - ./redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - automation-net

  # n8n — the workflow engine itself
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=${N8N_HOST:-n8n.yourdomain.com}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      # Database — tells n8n to use PostgreSQL instead of SQLite
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB:-n8n}
      - DB_POSTGRESDB_USER=${POSTGRES_USER:-n8n}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      # Queue mode — offloads execution to workers via Redis
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      # Security — disable telemetry and public API unless needed
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_PUBLIC_API_DISABLED=true
      # Timezone and binary data
      - GENERIC_TIMEZONE=${TZ:-Asia/Jakarta}
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
    volumes:
      - ./n8n-data:/home/node/.n8n
      # Mount local files so n8n can read/write homelab scripts
      - /opt/scripts:/opt/scripts:ro
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - automation-net

networks:
  automation-net:
    name: automation-net
    # Attach this network to your reverse proxy so n8n is accessible
    # externally (optional — keep it LAN-only if you VPN in)
    external: true

The .env file that accompanies this stack:

# .env — n8n secrets (chmod 600 this file)
POSTGRES_USER=n8n
POSTGRES_PASSWORD=generate-a-strong-random-password-here
POSTGRES_DB=n8n
# Generate with: openssl rand -base64 32
N8N_ENCRYPTION_KEY=your-base64-encryption-key-here
N8N_HOST=n8n.yourdomain.com
TZ=Asia/Jakarta

⚠️ Security note: The N8N_ENCRYPTION_KEY encrypts all credentials stored in n8n’s database. If you lose it, you lose access to every saved credential. Back it up in your password manager (/2026/06/vaultwarden-docker-compose-homelab/) and never commit it to git.

Essential n8n Credentials for Homelab Services

Once n8n is running at http://your-server:5678, configure credentials for the services it will orchestrate:

Building Your First Workflow: Proxmox Backup Alert

Here’s a practical n8n workflow that monitors Proxmox backup job completion and alerts you with an AI-generated summary. The workflow JSON can be imported directly into n8n:

{
  "name": "Proxmox Backup Monitor → Ollama Summary → Discord",
  "nodes": [
    {
      "name": "Cron Trigger",
      "type": "n8n-nodes-base.cron",
      "position": [250, 300],
      "parameters": {
        "triggerTimes": {
          "item": [{"mode": "everyHour"}]
        }
      }
    },
    {
      "name": "Check Proxmox Backup Status",
      "type": "n8n-nodes-base.httpRequest",
      "position": [450, 300],
      "parameters": {
        "url": "https://proxmox.local:8006/api2/json/nodes/pve/tasks",
        "authentication": "genericCredentialType",
        "genericAuthType": "httpHeaderAuth",
        "options": {
          "allowUnauthorizedCerts": true
        }
      }
    },
    {
      "name": "Filter Failed Backups",
      "type": "n8n-nodes-base.filter",
      "position": [650, 300],
      "parameters": {
        "conditions": {
          "string": [{
            "value1": "={{ $json.status }}",
            "operation": "equals",
            "value2": "FAILURE"
          }]
        }
      }
    },
    {
      "name": "Ollama: Summarize Failure",
      "type": "n8n-nodes-base.httpRequest",
      "position": [850, 300],
      "parameters": {
        "method": "POST",
        "url": "http://ollama:11434/api/generate",
        "body": {
          "model": "llama3.2:3b",
          "prompt": "=Summarize this Proxmox backup failure in one sentence for a homelab owner: {{ $json.status }} — task {{ $json.id }}",
          "stream": false
        }
      }
    },
    {
      "name": "Send Discord Alert",
      "type": "n8n-nodes-base.discord",
      "position": [1050, 300],
      "parameters": {
        "content": "=⚠️ Proxmox backup failure detected:\n{{ $json.response }}"
      }
    }
  ]
}

This workflow runs hourly, queries the Proxmox API for recent backup tasks, filters for failures, asks Ollama to summarize the failure in plain English, and posts the result to Discord. Total latency: ~3 seconds. Human involvement: zero.

Pillar 2: Self-Hosted Intelligence with Ollama

Why Local LLMs Belong in Your Automation Stack

Cloud AI APIs (OpenAI, Anthropic, Google) introduce three problems for automation: latency (API round-trips add 500ms–2s per call), cost (automation workflows run frequently — 24 checks/day × $0.01/request = $7.30/month for one workflow), and privacy (your logs, server names, and infrastructure details leave your network).

A local LLM running on your own hardware eliminates all three. Ollama makes this trivial — it bundles model weights, inference engine, and a REST API into a single binary. For automation tasks (summarization, classification, extracting structured data from logs), small models like Llama 3.2 3B or Phi-4 Mini perform exceptionally well with sub-second latency on consumer hardware.

Ollama Docker Compose + GPU/CPU Config

Add this to your automation stack:

# docker-compose.ollama.yml — Self-hosted LLM for automation intelligence
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    environment:
      # Keep models loaded in memory between requests for instant response
      - OLLAMA_KEEP_ALIVE=24h
      # Limit concurrent requests to avoid overwhelming CPU
      - OLLAMA_NUM_PARALLEL=2
      # Set max model load time (models larger than 7B need more time)
      - OLLAMA_MAX_LOADED_MODELS=2
    volumes:
      - ./ollama-data:/root/.ollama
    # GPU support — uncomment the appropriate section below
    # === Intel ARC / iGPU (A380, A770, N100/N305 iGPU) ===
    # devices:
    #   - /dev/dri:/dev/dri
    # === NVIDIA GPU ===
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: 1
    #           capabilities: [gpu]
    networks:
      - automation-net

  # OpenWebUI — optional ChatGPT-style interface for testing prompts
  openwebui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: openwebui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./openwebui-data:/app/backend/data
    networks:
      - automation-net

networks:
  automation-net:
    external: true

Model selection for automation tasks:

For homelab automation, start with Llama 3.2 3B. It runs comfortably on an Intel N100 with 8 GB RAM, responds in under a second, and handles summarization and classification tasks reliably. Pull it once:

docker exec -it ollama ollama pull llama3.2:3b

n8n → Ollama Integration: AI-Powered Alert Summarization

The n8n HTTP Request node calls Ollama’s /api/generate endpoint. The critical parameters:

{
  "model": "llama3.2:3b",
  "prompt": "You are a homelab monitoring assistant. A service alert fired: [ALERT DETAILS]. Summarize in 1-2 sentences what happened, probable cause, and recommended action. Be specific — mention the service name and relevant log keywords.",
  "stream": false,
  "options": {
    "temperature": 0.1,
    "num_predict": 150
  }
}

Why temperature: 0.1: Automation summaries need consistency, not creativity. Low temperature ensures the same alert produces similar, reliable output every time. Why num_predict: 150: You’re asking for a 1-2 sentence summary — 150 tokens is plenty and keeps latency under 1 second.

Use Case: Smart Log Analysis Pipeline

Beyond simple summarization, the n8n + Ollama combination can process structured logs. Here’s the architecture:

1. Cron trigger fires every 6 hours
2. Execute Command node runs journalctl --since "6 hours ago" -p err --no-pager | tail -50 on target servers via SSH
3. n8n merges log output into a single text block
4. HTTP Request to Ollama with prompt: “Analyze these 50 system log errors from the past 6 hours. Group them by severity and service. Flag any patterns that indicate a developing problem. Output as JSON with keys: ‘critical’, ‘warnings’, ‘patterns’, ‘recommendation’.”
5. n8n parses the JSON response and routes critical items to Discord, warnings to a daily digest

This replaces the traditional logwatch email you stopped reading six months ago with a structured, prioritized, AI-curated digest.

Pillar 3: Observability with Uptime Kuma & Webhook Triggers

Beyond Ping: Uptime Kuma as an Event Source

Uptime Kuma is the most deployed monitoring tool in the self-hosted world — and most people use 20% of its capabilities. The webhook notification type transforms it from a dashboard into an event source for your automation stack.

Configure Uptime Kuma monitors for each critical service, but instead of sending alerts to Discord directly, configure them to fire webhooks at n8n. This gives n8n the chance to enrich, filter, and route the alert before it reaches you.

For a complete Uptime Kuma deployment guide, see our setup walkthrough at /2026/06/uptime-kuma-docker-compose-homelab-2026/.

Webhook → n8n Trigger Architecture

In Uptime Kuma, create a notification of type Webhook with: - Post URL: http://n8n:5678/webhook/uptime-kuma-alert - Content-Type: application/json

The payload Uptime Kuma sends looks like this:

{
  "heartbeat": {
    "monitorID": 1,
    "status": 0,
    "time": "2026-06-11T03:14:22+07:00",
    "msg": "connect ECONNREFUSED 192.168.50.10:8096",
    "important": true
  },
  "monitor": {
    "id": 1,
    "name": "Jellyfin Media Server",
    "url": "http://192.168.50.10:8096",
    "type": "http",
    "interval": 60
  }
}

In n8n, the Webhook trigger node receives this payload. From there, your workflow can:

1. Deduplicate — check if this monitor already triggered within the last 10 minutes (avoid alert storms)
2. Enrich — query the container’s logs and resource usage
3. Analyze — send context to Ollama for root cause analysis
4. Attempt remediation — restart the container via Docker API or SSH
5. Escalate — if remediation fails after 2 attempts, send a notification to you

Building a Self-Healing Service Loop

Here’s the n8n workflow logic for a self-healing loop:

Webhook Trigger (Uptime Kuma alert)
  → IF (same monitor + last 10 min → already triggered)
      → Stop (deduplication — prevents alert storms)
  → Docker: Container Status (check if actually down)
      → IF (running but unreachable)
          → HTTP Request: Health check on container IP directly
          → IF (healthy) → Stop (false alarm — network blip)
      → Docker: Restart Container
      → Wait 30 seconds
      → HTTP Request: Health check
      → IF (healthy)
          → Discord: "Jellyfin auto-recovered after restart ✅"
          → Stop
      → IF (still down)
          → Ollama: Analyze docker logs for failure cause
          → Discord: "Jellyfin restart failed ❌ — AI analysis: [cause].
             Manual intervention needed. ssh user@host"

This is the “agentic” pattern in practice: detect, diagnose, remediate, escalate only when necessary. Each component is individually simple; the value comes from wiring them together.

The Complete Stack: Docker Compose Architecture

Network Design: Isolated Automation VLAN

The automation stack should live on its own Docker network, separate from your application containers. This prevents automation workflows from accidentally interfering with production services and makes it easy to control which services n8n can reach:

┌─────────────────────────────────────────────┐
│              automation-net                  │
│  ┌──────┐  ┌────────┐  ┌───────────────┐   │
│  │ n8n  │  │ Ollama │  │ Uptime Kuma   │   │
│  │:5678 │  │ :11434 │  │   :3001       │   │
│  └──┬───┘  └────────┘  └───────┬───────┘   │
│     │                           │            │
└─────┼───────────────────────────┼────────────┘
      │                           │
┌─────┼───────────────────────────┼────────────┐
│     │         app-net           │            │
│  ┌──┴──────────────────────────┴──┐         │
│  │   Jellyfin, Nextcloud, etc.    │         │
│  └────────────────────────────────┘         │
└──────────────────────────────────────────────┘

n8n can reach application containers via their Docker hostnames (if on the same network) or via the host’s LAN IP. Uptime Kuma monitors application services from the app-net side.

Environment Variables & Secrets Management

Centralize all secrets in a single .env file at the root of your automation stack directory:

# .env — Master secrets file for the automation stack
# Source this file before docker compose up

# PostgreSQL (n8n database)
POSTGRES_USER=n8n
POSTGRES_PASSWORD=CHANGE_ME_32_CHAR_MINIMUM
POSTGRES_DB=n8n

# n8n
N8N_ENCRYPTION_KEY=CHANGE_ME_OPENS_RAND_BASE64_32
N8N_HOST=automation.yourdomain.com

# Uptime Kuma
UPTIME_KUMA_PORT=3001

# Ollama
OLLAMA_KEEP_ALIVE=24h
OLLAMA_NUM_PARALLEL=2

# Timezone
TZ=Asia/Jakarta

Never commit .env to git. Add it to .gitignore immediately. Back it up separately in your password manager.

Resource Budget for Mini-PC Hosts

This stack runs well on modest hardware. Here’s what to expect:

An Intel N100 mini PC ($150–200) handles this entire stack comfortably, with room for 10–15 application containers alongside it. If you use GPU acceleration (Ollama with Intel iGPU or NVIDIA), CPU load during inference drops from ~80% to ~10%.

Real-World Use Cases

Use Case 1: Intelligent Backup Health Monitor

Problem: Backup scripts run on cron. When they fail, you might not notice for days — or until you need the backup.

Solution: n8n watches backup completion signals and verifies backup integrity:

1. Restic backup script writes exit status to a file or sends a webhook on completion
2. n8n receives the signal and checks: Was the backup successful? How large was it? Did the size change significantly from yesterday (possible corruption)?
3. If anomaly detected: n8n sends the backup log to Ollama for analysis
4. Alert goes to Discord with AI summary and recommended action

For backup tool setup (Restic, Kopia, Duplicati), see our backup strategy guide at /2026/06/self-hosted-backup-strategy-homelab-2026/.

Use Case 2: Security Alert Triage

Problem: Wazuh generates dozens of alerts daily. Most are informational. Finding the critical ones requires manual log review.

Solution: Wazuh → n8n → Ollama → Matrix/Discord pipeline:

1. Wazuh (see /2026/06/wazuh-siem-setup/) sends webhook for severity 10+ alerts
2. n8n receives the alert, extracts the rule ID, agent, and raw log
3. Ollama classifies the alert: “This is a brute-force SSH attempt from external IP 203.0.113.42 targeting user ‘admin’. 47 failed attempts in 5 minutes. Recommendation: verify fail2ban is active, consider blocking the /24.”
4. n8n routes based on classification: critical → immediate notification; high → hourly digest; medium → daily summary

Use Case 3: Automated Certificate Renewal Alert

Problem: Nginx Proxy Manager auto-renews Let’s Encrypt certificates — but when renewal fails, you only notice when the cert expires and browsers show warnings.

Solution:

1. n8n Cron trigger runs weekly
2. HTTP Request queries NPM API for certificate expiry dates
3. Filter for certificates expiring within 14 days
4. If any found: n8n triggers manual renewal via NPM API
5. Verify renewal 5 minutes later
6. If still failing: Ollama analyzes the error and n8n alerts with probable cause (“DNS challenge failed for domain X — check that Cloudflare API token hasn’t expired”)

FAQ

Is n8n stable enough for production homelab use?

Yes. n8n has been production-grade since v1.0 (late 2023). The current release (v1.8x as of June 2026) includes queue mode for reliable workflow execution, built-in error handling with retry logic, and PostgreSQL-backed persistence. Self-hosted instances at homelab scale (dozens of workflows, hundreds of executions/day) run stably on 512 MB RAM. The primary failure mode is database corruption with SQLite — which is why this guide uses PostgreSQL from the start.

Do I need a GPU for Ollama in automation workflows?

No. For automation tasks (summarization, classification, structured extraction), CPU inference with small models (3B–7B parameters) is fast enough. Llama 3.2 3B on an Intel N100 CPU produces ~12 tokens/second — a 50-token summary takes ~4 seconds. Since automation workflows are asynchronous (you’re not waiting in a chat window), this latency is perfectly acceptable. A GPU helps if you use larger models or do real-time interactive prompting through OpenWebUI.

How does this compare to Ansible or Terraform?

Ansible and Terraform are configuration management tools — they define desired state and enforce it. n8n is a workflow automation tool — it responds to events. They complement each other: use Ansible to provision your servers and deploy your Docker stacks, use n8n to monitor, alert, and auto-remediate when things drift from that desired state. A mature homelab uses both.

Can I run this on a Raspberry Pi or Intel N100?

An Intel N100 (4-core, 6W TDP, ~$150) handles the full stack with headroom. A Raspberry Pi 5 (8 GB) can run n8n + Uptime Kuma comfortably, but Ollama is marginal — the 3B models technically run but at 3–5 tokens/second with significant swap pressure. For Pi-based setups, consider offloading Ollama to a separate machine or using an external API (with the privacy trade-off understood).

What about data privacy with n8n?

Self-hosted n8n stores all workflow data, credentials, and execution history in your PostgreSQL database — nothing leaves your server unless you configure a node to send data externally. The telemetry is opt-out (N8N_DIAGNOSTICS_ENABLED=false). Credential encryption is AES-256-GCM with your encryption key. For maximum privacy, keep n8n on an isolated VLAN with no internet access and use it purely for LAN automation.

How do I migrate from Zapier or Make to n8n?

n8n provides a migration guide at docs.n8n.io. The high-level process: (1) document your existing Zaps/scenarios, (2) recreate them in n8n using equivalent nodes (the node library covers most Zapier/Make integrations), (3) run both in parallel for a week to verify parity, (4) cut over. For custom integrations, n8n’s HTTP Request + Code nodes can replicate any API-based Zap that doesn’t have a native n8n node.

Can I integrate Home Assistant into this stack?

Yes — and it’s a natural fit. n8n has a native Home Assistant node that can trigger on state changes (motion detected, door opened, temperature threshold crossed) and call services (turn on lights, lock doors, arm alarm). Combined with Ollama, you can build workflows like: motion detected at 2 AM → Ollama analyzes camera snapshot → if person detected (not cat) → send alert with annotated image to Discord. See our Home Assistant Docker guide (forthcoming) for the full setup.

What’s the backup strategy for n8n workflows?

n8n stores workflows in PostgreSQL alongside execution data. Back up both: (1) the PostgreSQL database via pg_dump or automated Docker PostgreSQL backups, and (2) the n8n data directory (./n8n-data) which contains binary files and the encryption key backup. n8n also supports manual workflow export as JSON from the UI — export critical workflows as version-controlled files in a git repo for an additional safety layer.

Do I need all three pillars to get started?

No. Start with one pillar and add the others incrementally: - Week 1: Deploy Uptime Kuma with Discord notifications. Get basic monitoring working. - Week 2: Deploy n8n and redirect Uptime Kuma alerts to it. Build the deduplication logic. - Week 3: Deploy Ollama and add AI summarization to your alert pipeline. - Week 4: Build the first self-healing workflow (auto-restart a non-critical container).

Each step delivers value independently. The full stack is the destination, not the starting line.

Conclusion: Start Small, Think System-Wide

The 2026 homelab automation stack isn’t a product you install — it’s an architecture you build incrementally. The three pillars — n8n for orchestration, Ollama for intelligence, and Uptime Kuma for observability — each solve a real problem on their own. Wired together, they create something greater: infrastructure that watches itself, thinks about what it sees, and acts before you notice there’s a problem.

Start with a single workflow. The Proxmox backup alert from Pillar 1 takes 20 minutes to set up and immediately reduces your backup-anxiety. Add the self-healing loop from Pillar 3 and your Jellyfin server recovers before your family texts you. Wire in Ollama and your alerts stop being raw JSON payloads and start being actionable summaries.

The future of self-hosting is agentic — and it’s available today. You already have the hardware. The software is free. The only missing piece is the wiring, and this guide is your schematic.

Want more? Continue building your automation foundation: - Deploy Uptime Kuma with our full Docker Compose guide at /2026/06/uptime-kuma-docker-compose-homelab-2026/ - Get Ollama running on Proxmox with GPU passthrough at /2026/06/ollama-proxmox-homelab/ - Secure remote access to your automation dashboard with /2026/06/self-hosted-vpn-homelab/ - Set up a Wazuh SIEM for the security pillar of your automation at /2026/06/wazuh-siem-setup/ - Browse our complete self-hosted services catalog at /2026/06/self-hosted-services-list/