Post

I’ve been building a small agentic GitOps infrastructure on k3s, and the main lesson is this: the agent should not be the platform. GitOps is the platform. The agent is an operator that works inside boundaries. Current shape of the stack: 1. k3s on Hetzner

A lean Kubernetes base. Single-node today, with the app and DB model designed so it can move toward HA without changing how apps are deployed. 2. Flux Operator One FluxInstance syncs the cluster root from Git. No app-of-apps sprawl, no imperative drift as the default operating model.

3. Forgejo Self-hosted Git source of truth, OCI registry, and Actions CI. The build runner is off-cluster so CI spikes don’t fight production workloads. 4. Flux image automation

CI pushes sortable image tags. Flux writes the promoted tag back into each app’s deploy/values.yaml, so deployments remain Git commits. 5. Gateway API + Traefik + cert-manager + external-dns Apps get HTTPRoutes. The shared gateway carries wildcard TLS. DNS lands in Cloudflare automatically.

6. CloudNativePG per project namespace Each project can own its app namespace and database, with WAL/base backups through Barman to S3-compatible object storage. 7. Tenant boundaries

Secrets stay encrypted in Git and are decrypted by Flux inside the cluster. Shared platform secrets are replicated intentionally, not copied around by hand. 9. Observability

Prometheus, Grafana, Loki, Tempo, Alloy, Alertmanager, blackbox probes, and runbooks make the system explainable before an agent touches it. 10. MCP + alert-to-agent loop

Flux, Grafana, and Forgejo MCP servers give the agent operational context. Alerts can spawn bounded jobs that diagnose, propose a PR, and report back with evidence. The important part: the agent is not a root shell with vibes.