Self-Hosted | Antoine Weill--Duflos

Everything I Self-Host: The Full Service Catalog

Mon, 13 Apr 2026 00:00:00 +0000

In a companion post I covered the infrastructure and orchestration layer of my homelab. This post is the full service catalog: everything that actually runs on top of that infrastructure.

Productivity & Data

Service	What it does
Nextcloud	File sync and collaboration
Paperless	Document management with OCR
Grocy	Grocery and household tracking
Actual	Budget tracking
Monica	Personal CRM
NocoDB	Database web UI (Airtable alternative)
n8n	Workflow automation

Media & Photos

Service	What it does
Immich (2 instances)	Photo management (Google Photos alternative)
Jellyfin	Media streaming server
Kavita	Ebook and manga reader
Prowlarr	Indexer management
Strava Stats	Fitness statistics dashboard

Home Automation & Security

Service	What it does
Home Assistant	Home automation hub
Frigate	NVR with AI object detection (details)
ESPHome	IoT firmware compiler for custom sensors

Communication

Service	What it does
Matrix	Self-hosted messaging (Synapse)
TT-RSS	RSS reader

AI & Compute

Service	What it does
Ollama	LLM inference on Intel Arc B580
llama.cpp	Vision model for Frigate scene descriptions
MCP Server	Obsidian vault API for AI assistants

Infrastructure

Service	What it does
Komodo	Deployment orchestration (details)
Gitea	Self-hosted Git
Traefik	Reverse proxy with auto TLS
Authelia	Single sign-on + two-factor authentication
Technitium DNS (x2)	Internal DNS zones (redundant)
Unbound	Recursive DNS resolver (on OPNsense)
OPNsense	Firewall, router, VPN
Omada Controller	WiFi access point management
Dockge	Docker Compose UI

Monitoring & Observability

Service	What it does
Prometheus	Metrics collection
Grafana	Dashboards and visualization
Uptime Kuma	Service uptime monitoring
cAdvisor (x2)	Container resource metrics
NetAlertX	Network device monitoring
LibreSpeed	LAN speed testing
MySpeed	Internet speed tracking over time
ntfy	Push notifications
Chrony + GPS	Stratum 1 NTP time source

Backup & Sync

Service	What it does
Proxmox Backup Server	VM and container backups
Resilio Sync (x2)	Cross-site file synchronization
Storj	Decentralized storage node

Security & Access

Service	What it does
Vaultwarden	Bitwarden-compatible password manager
Guacamole	Browser-based remote desktop
WireGuard	VPN (on OPNsense)

Web & Analytics

Service	What it does
Matomo	Privacy-respecting web analytics
Whoogle	Private Google search proxy

Why self-host all of this?

The obvious question is: why not just use cloud services? A few reasons:

Data sovereignty. My photos, documents, passwords, and communications stay on hardware I control. No third party is mining my data or training models on it.

No subscriptions. The total recurring cost is electricity. No monthly fees for photo storage, file sync, password management, or any of the other services that cloud providers love to charge for.

Reliability. My services don’t go down when someone else’s cloud has an outage. They also don’t get discontinued, acquired, or enshittified.

Learning. Running this infrastructure teaches you more about networking, Linux, containers, storage, and monitoring than any course ever could.

The trade-off is maintenance time. But with proper orchestration (see the Komodo post), that time is minimal. Most days, everything just runs.

Self-Hosted GitOps at Home: Managing 30+ Services with Komodo and a Proxmox Cluster

Mon, 13 Apr 2026 00:00:00 +0000

Running a handful of self-hosted services is easy. A single docker-compose up and you’re done. But at some point, “a handful” turns into 30+ stacks spread across multiple servers, and suddenly you need a real way to manage it all. That’s where my setup is today, and the most interesting part isn’t any single service: it’s the orchestration layer that ties everything together.

The problem

I run a lot of services at home. Photo management, home automation, file sync, NVR with AI detection, a personal CRM, RSS reader, document management, password manager, analytics, a Matrix chat server, LLM inference… the list goes on. Each one is a Docker Compose stack. Each one needs to be deployed, updated, monitored, and occasionally debugged.

For a while, I managed everything manually: SSH into a server, cd to the right directory, docker compose pull && docker compose up -d, check the logs. It works, but it doesn’t scale. When you’re managing services across six different hosts, you spend more time on logistics than on actually using the things you’ve built.

I needed a control plane.

The hardware: a Proxmox cluster

Everything runs on a Proxmox VE cluster built from repurposed enterprise hardware:

Node	CPU	RAM	Role
Primary	Xeon E5-2640 (12 cores @ 2.5 GHz)	32 GB	Main workloads
Secondary	Xeon E5-2430 (12 cores @ 2.2 GHz)	24 GB	Secondary workloads

These are old servers, the kind you can pick up for next to nothing. They’re loud, they draw power, and they have more compute than I’ll ever need. Perfect for a homelab.

The cluster runs about 40 LXC containers. LXC containers are the real workhorse here: they’re lighter than VMs, boot in seconds, and give you proper isolation without the overhead of full virtualization. Most of my Docker hosts are LXC containers with a few gigs of RAM each.

The servers: who does what

Not every LXC container runs Docker. Some run standalone services (DNS, monitoring, reverse proxy, authentication). But the Docker hosts are grouped logically in Komodo as “servers”: each one is a lightweight LXC container dedicated to running a set of related stacks. Komodo sees six servers in total: a couple of general-purpose Docker hosts, a dedicated Home Assistant instance, a photo management host, an alerting container, and the vault.

The vault is the most interesting one. It’s actually a NAS running OpenMediaVault with an Intel Arc B580 GPU installed. That one card handles hardware video decoding for Frigate’s camera streams, AI object detection, and LLM inference via Ollama, all at the same time. I wrote about the Frigate side of this in a previous post.

Enter Komodo

Komodo is a self-hosted deployment manager. Think of it as a lightweight alternative to Portainer or Coolify, but with a focus on managing Docker Compose stacks across multiple servers. Here’s why I picked it:

Multi-server management from a single dashboard. One UI to see and control every stack on every server.
Git-based deployments. Stacks can pull their compose files from a Git repository. Push a change, and Komodo deploys it.
Webhook-triggered updates. My self-hosted Gitea instance sends webhooks to Komodo on every push. The stack redeploys automatically.
Auto-update for container images. Komodo can poll for new images and update containers without manual intervention.
Environment variable management. Secrets and config live in Komodo, not in the Git repo.

The architecture looks like this: a central Komodo Core instance runs on one server, and a lightweight Komodo Periphery agent runs on each remote host. The core talks to periphery agents to deploy and manage stacks. It’s simple, reliable, and doesn’t require Kubernetes.

The GitOps workflow

This is where it gets interesting. About half of my stacks are managed through Git repositories on my self-hosted Gitea instance. The workflow:

I edit a docker-compose.yml in a Gitea repo
I push the change
Gitea fires a webhook to Komodo
Komodo pulls the updated compose file
Komodo redeploys the stack on the target server

For stacks that don’t need version-controlled compose files (simpler services), Komodo manages the files directly on the host. I can still edit them through the Komodo UI, but they aren’t backed by Git.

The split is intentional. Complex stacks with multiple services, custom configs, or frequent changes live in Git. Simple single-container services are managed inline. This avoids the overhead of Git for things that don’t need it, while giving me full version history and rollback for the things that do.

Home Assistant: a special case

Home Assistant deserves a mention because it’s managed differently. Its entire configuration is in a Gitea repo, and Komodo watches it with both polling and webhooks. When I push a config change, Home Assistant gets the update automatically. No more SSH-ing in to edit configuration.yaml.

The network: OPNsense and VLANs

Running dozens of services on a flat network would be a security nightmare. I use OPNsense as my firewall/router with multiple VLANs:

Network segment	Purpose
Main	Servers and trusted devices
IoT	Smart home devices (cameras, sensors, ESPHome)
Lab	Experimental VMs and containers
WireGuard	VPN access from outside

IoT devices can’t talk to each other or to the main network directly; they can only reach the services they need (Home Assistant, Frigate). The lab network is isolated for testing. WireGuard gives me secure remote access to everything.

DNS: Unbound + Technitium

DNS is handled by two layers working together:

Unbound runs on OPNsense itself as the primary recursive resolver. It handles upstream DNS resolution with DNSSEC validation, and it’s fast: queries are answered from cache most of the time.
Technitium DNS (running in two LXC containers for redundancy) handles internal DNS zones, so I can reach services by name instead of memorizing IPs. It also provides split-horizon DNS for services that need different answers internally vs. externally.

NTP: GPS-disciplined time with Chrony

One detail I’m particularly happy with: the network’s time source is a USB GPS receiver (BN-808, u-blox M8N chipset) connected to a dedicated LXC container running Chrony. The GPS provides Stratum 1 time to the entire network.

The setup isn’t perfect: USB GPS doesn’t support PPS (Pulse Per Second), so precision is limited to about 40ms due to USB latency. Chrony compensates for this with a manual offset correction and falls back to internet NTP servers (Cloudflare, public pools) when needed. OPNsense distributes the time to all clients on the network.

It’s overkill for a homelab, but there’s something satisfying about having your own GPS-disciplined time source rather than depending entirely on external NTP pools.

Authelia provides single sign-on with two-factor authentication in front of all web-facing services, with Traefik as the reverse proxy.

Storage: the vault NAS

The “vault” server is an OpenMediaVault NAS that does double duty as a compute node. It has 8 drives, one NVMe for the OS and 7 HDDs ranging from 2 TB to 16 TB:

Drive	Model	Capacity
NVMe	WD BLACK SN770	500 GB (boot)
HDD 1	Seagate IronWolf	10 TB
HDD 2	WD	10 TB
HDD 3	WD	12 TB
HDD 4	WD Green	2 TB
HDD 5	WD Red	2 TB
HDD 6	Seagate IronWolf Pro	16 TB
HDD 7	HGST Deskstar NAS	6 TB

A mix of whatever drives I had or found on sale. The beauty of my storage setup is that it doesn’t care about uniformity.

The nested mergerfs architecture

Storage is organized in layers using mergerfs pools:

A parity-protected pool: a mergerfs pool combining 3 btrfs-formatted drives. These drives are protected by SnapRAID parity (the 16 TB Seagate acts as the parity drive).
A main pool: a super-pool that merges the parity-protected pool with an additional direct drive into one large namespace. This is where Immich stores photos, Kavita stores books, and Frigate stores video clips.
A read-only photos pool: a mergerfs view that aggregates all my photo directories (personal photos, DCIM camera imports) into a single mount point for easy access and import.

SnapRAID does parity syncs on a schedule (not real-time like traditional RAID), which means:

There’s no write penalty; writes go directly to the underlying btrfs drives
If a drive fails, I can recover its contents from parity + the remaining drives
Drives can be different sizes (and they very much are)
Each drive is a standard filesystem you can read independently in an emergency

The trade-off is that data written between parity syncs is unprotected. For a homelab storing photos and media, that’s an acceptable risk.

Proxmox Backup Server also runs in Docker on this same NAS, providing VM and container backups from the Proxmox cluster. Both Proxmox nodes mount the vault’s PBS storage directly.

Monitoring and alerting

You can’t manage what you can’t see. The monitoring stack:

Tool	Role
Prometheus	Metrics collection
Grafana	Dashboards and visualization
Uptime Kuma	Service uptime monitoring
cAdvisor	Container resource metrics
NetAlertX	Network device monitoring
ntfy	Push notifications to my phone

Komodo itself integrates with ntfy for deployment alerts. If a stack fails to deploy or a container goes unhealthy, I get a push notification immediately. The ntfy-alerter stack maps Komodo alert severity to ntfy priority levels, so a critical alert gets a high-priority push that bypasses Do Not Disturb.

The whole thing runs 24/7, manages itself for the most part, and costs nothing beyond electricity and the initial hardware investment. When something does need attention, Komodo and ntfy make sure I know about it, and the GitOps workflow means I can fix most things with a git push from my phone.

If you’re running more than a handful of self-hosted services and you’re still managing them manually, give Komodo a look. It turned my homelab from a collection of Docker hosts into a proper managed platform.

Ditching Cloud Cameras: Self-Hosted Security with Frigate, Tapo, and an Intel Arc B580

Sun, 12 Apr 2026 00:00:00 +0000

I live in Canada. At some point I started noticing signs that someone (or something) had been visiting my garden. Could be an animal, could be a person. Hard to tell. So I figured it was time to put up some cameras. What started as a simple purchase ended up becoming a proper self-hosted setup with AI-based detection. Here’s the story.

The starting point: Amazon Blink

I went with Amazon Blink cameras first. They’re cheap, battery-powered, motion-triggered, and they handle Canadian winters without issues. No wiring needed, no network setup. Just stick them up and go.

The problem? False positives. Constantly. A branch moving in the wind, a shadow, snowfall… everything triggers an alert. After a few weeks of this you either start ignoring all notifications (which defeats the whole point) or you waste time scrubbing through clips of nothing. Neither option is great.

That’s when I started reading about Frigate and RTSP cameras, and things got interesting.

The new setup

Tapo cameras

I swapped the Blinks for Tapo cameras. The big deal with these is that they support RTSP streaming natively and have a micro SD card slot for local recording. So you get:

A local backup on the SD card even if your network goes down
A direct video stream over WiFi to your NVR, no cloud relay involved
Cameras that work 100% on your local network, no account or subscription required

Frigate

Frigate is an open-source NVR (network video recorder) and it has come a really long way. It gives you:

A single dashboard with live views from all your cameras
Motion detection as a first-pass filter
AI object detection that tells you what moved (person, animal, car…)
Full scene descriptions that explain what is actually happening in the clip

That last part is the game changer. Instead of getting “motion detected” you get something like this:

Person picks up bicycle wheel A person enters the frame from the bottom right and walks toward the center of the area where a bicycle wheel is lying on the ground. The person bends down, picks up the bicycle wheel, and stands holding it. The individual then turns and walks back toward the camera, exiting the frame at the bottom.

With that kind of detail, I only get notified when something real is going on.

Hardware: Intel Arc B580

I added an Intel Arc B580 (Battlemage) to my server. This one card does double duty:

Video decoding: hardware-accelerated decode of all the RTSP streams
AI inference: runs the detection and description models

The B580 support in Frigate is actually pretty solid. Both workloads run on the GPU at the same time, so the CPU barely notices. The descriptions aren’t always perfect but they’re more than good enough to filter out noise and only alert on real events.

One card, reasonable power draw, no need for a separate ML box. Works well.

The scene description model: llama.cpp + Vulkan

The AI descriptions don’t come from the cloud either. I run a local LLM server using llama.cpp with Vulkan backend on the B580. Frigate sends snapshots to it via an OpenAI-compatible API endpoint, and the model returns scene descriptions.

Here’s the docker-compose for the inference server:

version: "3.9"
services:
  llama-server-intel:
    image: ghcr.io/ggml-org/llama.cpp:server-vulkan
    container_name: llama-server-intel
    restart: unless-stopped
    devices:
      - /dev/dri:/dev/dri
    volumes:
      - /var/models:/models
    ports:
      - 4040:8080
    environment:
      # Workaround for Mesa ANV driver fp16 compute bug on Intel iGPUs.
      # Safe to set even on dGPUs (B580), ignored if not needed.
      - GGML_VK_DISABLE_F16=${GGML_VK_DISABLE_F16:-0}
    command: >
      --model /models/Qwen3.5-9B-UD-Q4_K_XL.gguf
      --mmproj /models/mmproj/mmproj9B-BF16.gguf
      --n-gpu-layers 99
      --ctx-size ${LLAMA_CTX_SIZE:-131072}
      --host 0.0.0.0
      --port 8080

The model I’m using is Qwen3.5-9B with a vision projector, quantized to fit in 12 GB of VRAM. Vulkan turns out to be 30-60% faster than SYCL on Intel Arc GPUs, so it’s the right backend for this card.

Docker setup for Frigate

Here’s the Frigate docker-compose:

version: "3.9"
services:
  frigate:
    container_name: frigate
    privileged: true
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: 512mb
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./config:/config
      - ./model:/model
      - ./storage:/media/frigate
      - /dev/dri/renderD128:/dev/dri/renderD128
      - type: tmpfs
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - 5005:5000
      - 8971:8971
      - 8554:8554 # RTSP feeds
      - 8555:8555/tcp # WebRTC over tcp
      - 8555:8555/udp # WebRTC over udp
      - 1984:1984
    environment:
      PLUS_API_KEY: ${PLUS_API_KEY} # optional, for Frigate+
      FRIGATE_RTSP_PASSWORD: ${FRIGATE_RTSP_PASSWORD}
      OPENAI_BASE_URL: http://llama-server-intel:8080/v1 # points to the local LLM

A few things to note:

/dev/dri/renderD128 gives Frigate access to the B580 for hardware video decoding
The tmpfs mount is used as a fast cache for clips being processed
shm_size depends on how many camera streams you run (512 MB is fine for a few cameras)
OPENAI_BASE_URL points to the llama.cpp server for scene descriptions. Frigate uses the OpenAI-compatible API, so any local server that speaks that protocol works
Put your secrets in a .env file next to the docker-compose, not in the YAML

Home Assistant

Everything plugs into Home Assistant:

Camera feeds and Frigate events show up on the HA dashboard
Notifications go through HA’s automation engine
Remote access through HA’s built-in secure connection

Cameras detect, Frigate analyzes, Home Assistant notifies. All local.

Why bother self-hosting cameras?

Your data stays yours. No footage leaves your network. No cloud provider is storing or processing your video
No subscriptions. Cloud cameras love charging monthly for “premium” features like person detection. This costs nothing after the initial hardware
Way fewer false positives. AI detection vs. basic motion sensing is night and day
Actually useful alerts. You know what happened, not just that something moved
Works offline. SD card backup + local NVR means the system keeps recording even if your internet goes down

Summary

Component	What it does
Tapo cameras	RTSP stream + local SD card recording
Frigate	Open-source NVR with AI object detection
Intel Arc B580	Video decoding + AI inference on one card
Home Assistant	Dashboard, notifications, remote access
Local server	Runs Frigate and Home Assistant

Final thoughts

It took a bit of time to set up, but I’m really happy with how this turned out. No more cloud dependency, no subscriptions, and the false positive problem is basically solved. The AI descriptions are surprisingly good and the B580 handles everything without breaking a sweat.

If you’re fed up with cloud camera notifications about tree branches, give Frigate a look. The project has matured a lot and with Home Assistant it makes for a solid, reliable system.

Most importantly: I can finally stop checking my phone every time the wind blows.