Post

Arthur
@arthurliebhardt.com

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

Arthur
@arthurliebhardt.com

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.

0 reposts0 likes

Arthur
@arthurliebhardt.com

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

Arthur
@arthurliebhardt.com

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.

Arthur
@arthurliebhardt.com

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

Arthur
@arthurliebhardt.com

One generic Helm chart, explicit app registration, per-project service-account impersonation, scoped RBAC, quotas, limit ranges, PSA labels, and default-deny egress. 8. SOPS + age