Skip to main content

​
The basics

Yes. Lumovi is free and open source under the Apache 2.0 license, on your desktop and in your cluster. There are no accounts and no telemetry. It’s made in spare time; if it saves you time, you can sponsor its development.
It’s the same app either way, so pick what fits:Plenty of teams use both. See Install the desktop app and Run it in your cluster.
No. Lumovi talks to the API server itself. It still shows the equivalent kubectl command for every change, so you can learn it, copy it or script it. Helm is needed only to change Helm releases; looking at them needs nothing.
Kubernetes 1.25 or later. From 1.27, Lumovi also explains fields from the cluster’s own OpenAPI schema. When it runs in your cluster, signing in with a token needs 1.28 or later.
Yes. Lumovi reads your kubeconfig the way kubectl does, with client certificates, tokens and exec credential plugins like gke-gcloud-auth-plugin, aws eks get-token and kubelogin. If kubectl can reach a cluster with your kubeconfig, Lumovi can too. See Connecting clusters.
Lumovi is built around one question: is this cluster healthy, and if not, where should I look first? So it shows problems before everything else, sets usage against capacity, and keeps the details one click away. It’s neither a terminal nor a wall of tables.When you change something, it’s careful: it asks the cluster what you’re allowed to do, shows the kubectl command, checks edits with a dry run, and offers undo. And it’s the same app on your desktop and in your cluster, so a team can share it without installing anything.

​
Your data and your clusters

No. It reads your kubeconfig and never writes to it. Managing kubeconfig files, like adding contexts or signing in to cloud providers, is deliberately left to the tools made for it.
No. There’s no telemetry and no account. The desktop app talks to your clusters, and to a few other places only when you use what needs them, like update checks and chart search. See Privacy and security for the full list.
Lumovi needs to reach your clusters, and nothing else. Without the internet, everything works except looking for new versions, searching Artifact Hub, and fetching charts from public repositories.
It’s built not to. Changes are always explicit: an action, a dialog that names the cluster and shows the command, and a confirmation. Destructive dialogs start on Cancel, and risky deletes, or anything in a cluster named like production, ask you to type the name first. For a cluster you only want to look at, turn on read-only mode. See Changing things safely.
Only what you want to do. Lumovi acts with your own credentials and RBAC, so a read-only view role is enough to look around. It asks the cluster what you may do before offering an action, and says why when you can’t. See Permissions.

​
Using it

Yes. The desktop app lists every context in your kubeconfig on its start screen, with whether each one answers. Switch between them from the cluster menu at the top of the sidebar, or with ⌘K. Each cluster remembers its own namespace, read-only setting and usage history source.Lumovi in your cluster shows the one cluster it runs in.
Yes. Lists load in chunks of 500 and are paginated and virtualized, so thousands of pods stay smooth. They stop at 5,000 objects by default, with a note saying so; a label selector narrows a list on the server. Busy lists refresh less often.
Yes, every kind the cluster serves, found through API discovery. They get the columns kubectl get prints and a status read from their conditions. Views for popular projects (cert-manager, Argo CD, Flux, Karpenter and more) add better columns, links and actions, and each project’s add-on gives it an entry in the sidebar, with everything it runs in one list. You can write your own views and add-ons too. See Custom resources.
From a Prometheus or VictoriaMetrics in the cluster, which Lumovi finds by itself and reaches through the API server with your own credentials. Live usage comes from metrics-server. See Usage history.
Yes. Lumovi follows your system, or you can pick light or dark from the theme button at the bottom of the sidebar, or with ⌘K.

​
The project

Lumovi was started by Peter Kota, first as a tool for work: an app to open a cluster and know in a second whether it’s healthy. It’s developed in the open with its contributors on GitHub.
Lumovi is the same app, with a new name. Lumovi 1.0.0 has everything KubeStacks had. A few things don’t carry over:
  • Installed copies don’t update into Lumovi. Download Lumovi and install it. It’s a separate app, so KubeStacks stays until you remove it.
  • Settings start over. Your theme, read-only clusters, usage history sources and the rest stay in KubeStacks’ own folder, which Lumovi doesn’t read. Your kubeconfig is read as before.
  • Your own views go in ~/.lumovi/views instead of ~/.kubestacks/views, and start with apiVersion: lumovi.dev/v1alpha1 instead of kubestacks.dev/v1alpha1. Lumovi doesn’t use a file with the old apiVersion, and lists it under API resources.
  • Environment variables start with LUMOVI_ instead of KUBESTACKS_.
  • In your cluster, the image is ghcr.io/lumovi/lumovi and the chart oci://ghcr.io/lumovi/charts/lumovi, and the server’s settings are LUMOVI_* variables. See Install Lumovi in your cluster.
  • Report what’s wrong, or what’s missing, in an issue.
  • Add support for a tool you run. An add-on and views for it are YAML, checked against the tool’s CRDs, with no code to write. It’s an easy and welcome first contribution. See Built-in views for what Lumovi has, and Build from source for how to add one.
  • Contribute. Pull requests are welcome; for anything bigger than a small fix, open an issue first. See Build from source.
  • Sponsor its development on GitHub Sponsors. The desktop app has a link in Help → Sponsor Lumovi… too.
  • Star it on GitHub, so others find it.
Privately, please, through a GitHub security advisory. See Reporting a vulnerability.