talos-argocd-proxmox

A GitOps Kubernetes homelab on Talos Linux with self-managing ArgoCD. ApplicationSets discover app directories. Per-PVC Kopiur resources declare backup and restore behavior. After the operator rebuilds Talos and seeds Argo, protected volumes restore automatically from the off-cluster repository.

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

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, placed by drive endurance; mostly one replica, with two for data that can't be re-created. NAS provides bulk files and off-cluster backups. Current machines and capacity.
• Backup: kopiur (Kopia-native) → RustFS S3, per-PVC SnapshotPolicy/Restore with restore-before-bind
• Database: plain Postgres Deployments backed up by kopiur — daily snapshots (every 6 hours for data that can't be re-created), restore-before-bind
• Hosts: Proxmox and Pi operating-system settings applied with Ansible from host-monitoring/ (guide)
• Secrets: 1Password Connect + External Secrets Operator
• Observability: kube-prometheus-stack, Loki, Tempo, OpenTelemetry
• AI: the production backend serves official qwen3.8-27b FP8 through vLLM on both RTX 3090s. The local AI starter kit lists the parts and the build order. The model catalog owns the local backend and Pi's optional OpenRouter DeepSeek Flash route; use the scale-swap runbook to change the card owner. Hermes is the always-on agent with cron, memory, chat platforms, and in-pod Claude Code and Codex for pull requests. It replaced Paseo, which is off.

Reading order

Start with the easy guide, then follow the sidebar from top to bottom: understand the platform, learn how to operate it, explore the hardware, review its measured performance, and consider future changes.

Sidebar section	Use it for	Start here
Overview	Understand how the platform works	The easy guide
Operations	Learn the deployed platform and its procedures	Operations guide
Inventory	Machines, disks, hardware health, and workload placement	Inventory
Audits	Performance measurements, limitations, and ranked recommendations	Audits
Ongoing research	Options being considered and the tests needed to decide	Research

For current upgrade priorities, jump to the September 20 decision report.

The full inventory and explorer were refreshed on October 15. Historical benchmarks retain their collection dates. An inventory is not a live dashboard, and a research proposal is not a deployed change.

Frequent tasks

1. Find a machine or its disks: the disk map shows every physical disk, what it holds, and where new data should go. Explore the lab and the hardware diagnostics report hold the dated hardware snapshots.
2. Understand NAS speeds and RAM: NAS performance separates physical-disk reads, RAM-cache reads, and flushed writes.
3. Add or troubleshoot backups: start with the kopiur architecture, then mover permissions.
4. Recover the platform: use the disaster recovery runbook. The backup simulator provides a safe browser-only walkthrough.
5. Release a worker: use the Temporal safe deployment runbook.
6. Keep SSD wear down: follow the disk-write rules and check the top writers there.
7. Change a Proxmox host or the Pi: those machines are configured with Ansible, not Argo CD. Use physical hosts with Ansible.

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.

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.