| Hi HN, 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! |