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!
No comments yet.
