A few days ago, I shared Tenant Operator – a Kubernetes operator for multi-tenancy. After valuable feedback and production experience, I've evolved it into Lynq with a clearer scope and better documentation.

What it does: Lynq watches your database (MySQL) and automatically provisions Kubernetes resources based on active rows. Add a database entry → get a full stack (Deployment, Service, Ingress, whatever you define) in ~30 seconds. Update or delete the row → everything syncs automatically.

Key improvements since the original post:

- Generalized beyond tenants: now handles any DB-driven infrastructure pattern - Built-in drift detection, conflict resolution, and dependency ordering - Much clearer documentation showing real-world use cases - Production-tested workflow patterns (customer isolation, dynamic environments, self-service infra)

The core insight remains: your database is already the source of truth for dynamic entities (customers, teams, environments). Why maintain separate YAML files and manual kubectl workflows?

Real-world example: New customer signs up → DB insert → isolated namespace + all resources appear automatically. No CI/CD pipeline, no Helm release tracking, no manual kubectl apply.

This isn't for everyone – if your infrastructure is mostly static, traditional GitOps is simpler. But if you're managing 100+ dynamic nodes where configuration lives in a database, this approach eliminates a lot of operational overhead.

I'm looking for feedback on: - Design patterns you'd want to support - Edge cases I might have missed - Documentation clarity (especially for those new to operators)

Site: https://lynq.sh/ GitHub: https://github.com/k8s-lynq/lynq

Happy to answer any questions!