nteresting approach — especially the local-first angle.
Curious how you're thinking about state consistency when multiple users interact with the system?
In a different context (hiring systems), we’ve seen local vs centralized trade-offs become a big design constraint.
Local binary connects directly to the k8s cluster (queries the API server) using the same Go SDK as k8s itself. Keep a local cache and listens to live updates using k8s native watchers.
The load on the server is not that much for a reasonable number of users, each just syncs the data to their local client.
It also supports install with Helm in the cluster, so a single installation can serve any number of users - data gets synced once (continuously), every user gets served the local embedded UI. You probably want to integrate with auth for that - supports proxy and OIDC natively.
Simple and very useful.
nteresting approach — especially the local-first angle. Curious how you're thinking about state consistency when multiple users interact with the system?
In a different context (hiring systems), we’ve seen local vs centralized trade-offs become a big design constraint.
Local binary connects directly to the k8s cluster (queries the API server) using the same Go SDK as k8s itself. Keep a local cache and listens to live updates using k8s native watchers. The load on the server is not that much for a reasonable number of users, each just syncs the data to their local client.
It also supports install with Helm in the cluster, so a single installation can serve any number of users - data gets synced once (continuously), every user gets served the local embedded UI. You probably want to integrate with auth for that - supports proxy and OIDC natively.
Nice!
Looks Great!
Looks awesome!
[flagged]