BLUF: A complete self-hosted AI + Kubernetes stack in 2026 needs five layers working together: an immutable OS (Talos), a kernel-level network layer (Cilium), a GitOps delivery mechanism (ArgoCD), an automation/agent layer (n8n with local LLMs), and a data layer that doesn't require a separate vector database (PostgreSQL + pgvector). Here's how they fit together in a stack I actually run.

Most "reference architecture" posts describe a stack someone built once for a conference talk. This one describes infrastructure I run continuously, on my own Proxmox homelab, because I don't trust advice I haven't personally operated under real conditions.

The Five Layers

┌─────────────────────────────────────────────┐
│  n8n (automation + AI agent orchestration)    │
├─────────────────────────────────────────────┤
│  PostgreSQL + pgvector (data + RAG storage)   │
├─────────────────────────────────────────────┤
│  ArgoCD (GitOps — Git is the source of truth) │
├─────────────────────────────────────────────┤
│  Cilium (eBPF networking + service mesh)      │
├─────────────────────────────────────────────┤
│  Talos Linux (immutable Kubernetes OS)        │
└─────────────────────────────────────────────┘
              Proxmox VE (bare metal)

Layer 1: Talos as the Foundation

Every node in the cluster runs Talos — no SSH, no package manager, API-driven upgrades. This is the layer that makes the rest of the stack low-maintenance: I'm not patching individual boxes, I'm applying declarative machine configs.

cluster:
  network:
    cni:
      name: cilium
  network:
    podSubnets: ["10.244.0.0/16"]

Layer 2: Cilium for Networking and Observability

Cilium handles CNI, network policy, and service-mesh capability without a sidecar per pod — critical on homelab-scale hardware where per-pod memory overhead actually matters. It also gives me L3–L7 visibility into what's talking to what, which matters more in a self-hosted environment than in a managed cloud where some of that is handled for you.

Layer 3: ArgoCD for GitOps Delivery

Nothing gets deployed by running kubectl apply by hand. Every change goes through Git, and ArgoCD reconciles the live cluster against it automatically:

syncPolicy:
  automated:
    selfHeal: true
    prune: true

This is what makes the homelab reproducible — if a node dies and gets rebuilt, the workloads come back exactly as declared, not as a snapshot of whatever manual tweaks accumulated over months.

Layer 4: PostgreSQL + pgvector for Data and RAG

One database handles both relational data and vector embeddings for the RAG pipelines I run against local LLMs. No separate vector database, no second system to back up and secure:

CREATE EXTENSION IF NOT EXISTS vector;
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

Layer 5: n8n as the Automation and Agent Layer

n8n sits on top of everything else, orchestrating workflows that call local LLMs (via Ollama), query the PostgreSQL/pgvector layer for RAG context, and — increasingly — expose specific workflows as MCP tools that AI agents can call directly. This is the layer where the other four become useful to an actual end user instead of just being well-architected infrastructure for its own sake.

Why I Run This Myself Instead of Just Writing About It

Every post on this site about Talos, Cilium, self-hosted LLMs, or GitOps drift comes from operating this exact stack, not from reading someone else's documentation. When I write that selfHeal: true actually reverts manual changes on the next reconciliation loop, it's because I've watched it happen on my own cluster after fat-fingering a kubectl edit. When I write that pgvector handles RAG workloads without a separate vector database, it's because that's the database serving my own automation workflows right now.

What I'd Change for a Production Client Deployment

A homelab can tolerate a single point of failure that a client's production environment can't. For client work, this same stack gets: multi-node control planes instead of one, automated backups off-site instead of local snapshots, and a proper secrets management layer (External Secrets Operator) instead of the shortcuts that are fine for a personal lab.

Bottom Line

This isn't a theoretical reference architecture — it's the actual stack behind this blog, my automation client work, and my own AI experiments. If you're evaluating whether to build something similar, every individual layer above has its own dedicated post on this site with the specific trade-offs, costs, and failure modes I've hit running it for real.

Need help implementing this? I help teams architect and scale this exact infrastructure. Explore my consulting and freelance services.