Skip to content

talos-argocd-proxmox

A production-grade GitOps Kubernetes cluster on Talos Linux with self-managing ArgoCD: applications are discovered from directory structure, storage is backed up declaratively via PVC labels, and the whole cluster can be destroyed and rebuilt unattended — restores included.

Source: mitchross/talos-argocd-proxmox · This site renders docs/ from that repo.

Logical overview of the Proxmox, Talos, Argo CD, networking, secrets, storage, and backup platform

Git reconstructs desired state, 1Password reconstructs credentials, and RustFS reconstructs protected data. Open the full-size platform map.

The point

The whole cluster can be destroyed and rebuilt with every protected volume restored automatically from the off-cluster Kopia repository — no manual storage steps. See disaster recovery.

Stack

  • OS: Talos Linux on Proxmox VMs, provisioned via Omni / Sidero
  • CNI: Cilium with Gateway API + LoadBalancer
  • GitOps: ArgoCD (self-managing) + ApplicationSets for auto-discovery
  • Storage: Longhorn V1 engine, currently 1 replica because the active control-plane + worker VMs share one physical Proxmox failure domain; replica count is designed to rise when workers span additional hosts
  • Backup: kopiur (Kopia-native) → RustFS S3, per-PVC SnapshotPolicy/Restore with restore-before-bind
  • Database: CloudNativePG (Postgres) with Barman backups to S3
  • Secrets: 1Password Connect + External Secrets Operator
  • Observability: kube-prometheus-stack, Loki, Tempo, OpenTelemetry
  • AI: vLLM (Qwen3.6-27B, default app inference) + llama-cpp (Qwen3.6-35B multimodal — vision→image + preset playground) on mutually-exclusive whole-card GPUs (scale-swap runbook)

Documentation

Every page follows the documentation reader contract: state the current posture, explain unfamiliar choices, provide verifiable steps, and include failure/rollback guidance for risky operations.

  • 📖 The easy guide — share this one

    The whole system from zero: GitOps → sync waves → Kustomize components → kopiur → restore-before-bind. Real YAML, an adoption ladder for "I just want to try kopiur", and the colleague FAQ.

    → easy-guide.md

  • 💾 kopiur backup architecture — the one doc

    The pieces, the component pattern, backup + restore flow diagrams, and the 6-step add-a-backup checklist.

    → kopiur-backup-architecture.md

  • ☠️ Disaster recovery — the runbook

    Destroy → rebuild → restore: pre-nuke checklist, restore-wave expectations, and the restore canary.

    → disaster-recovery.md

  • 🗄️ Storage architecture — operator's reference

    Design decisions, who-provides-what, day-2 operations (enable / exempt / drill), troubleshooting, and the honest limitations.

    → storage-architecture.md

💾 More storage & backups

Backups are kopiur (Kopia-native operator).

🗃️ Domains

Adopting any of this

This is one operator's homelab, not a product. The patterns are portable — the label-driven backup contract, the off-cluster repository, the restore-canary idea, the sync-wave bootstrap — but the image tags, hostnames, and 1Password item names are not. Start with storage-architecture.md.