Lumovi is a fast Kubernetes dashboard. It shows what’s healthy, what’s struggling and where your capacity goes: on your desktop for every cluster in your kubeconfig, or in a browser for the whole team, from one cluster to a fleet.
Hover a pod. Click a failing one to restart it.Tap a pod. Tap a failing one again to restart it.Everything’s running. Nice work.
Lumovi reads your kubeconfig and asks every cluster’s API server for its version, so you see which ones answer, how fast, and which don’t. Open one, and switch with ⌘K from anywhere.
Pick a cluster and Lumovi shows you how it’s doing. Problems sort to the top, usage sits next to capacity, and the details are one click away. It follows your system’s light or dark, and every status has an icon and a label, never color alone.
What needs attention, live usage against what’s allocatable, and every node’s load. Overview
Deployments, StatefulSets, DaemonSets, Jobs and CronJobs in one list. Failing ones first. Workloads
Pick a few rows, or a hundred, and restart or delete them together. Several at once
History from your Prometheus or VictoriaMetrics, found for you. Drag across a chart to zoom. Usage history
What each workload should request, from a week of its use. Checked by the API server first, with undo. Usage history
Every pod of a workload, merged in the order lines were written. Logs
A shell on any node, as root, or in any container, with a debug container for pods that have none. Shells on nodes
On the desktop, your own shell along the bottom, with kubectl and helm already pointed at this cluster. Terminals
Releases, their values and every revision, with a diff between any two. Helm releases
Each tool the cluster runs gets a page. Karpenter’s: node pools against their limits, and who’s waiting. Built-in views
Press G then a letter to switch views, just like in the app. Every shortcut
Every object has a map: what leads to it, from the gateway and routes to the services and policies in front of it, and what it uses, from its pods and the ConfigMaps and Secrets they read to the nodes they run on. Point at anything to trace its chain. What’s missing or unwell takes its color, so you see it first.
Above it, what leads to it; below, what it uses.Routes, ownsUses
checkout has crash-looped since its last rollout. Roll it back, watch its pods come up one by one, and undo it if that wasn’t it. Lumovi checks your permissions first.
Deployment in shop on demo
kubectl rollout undo deployment/checkout -n shop --context demo --to-revision=6Each node as the scheduler sees it: what its pods request against what it can give, and what they really use. When a pod waits for room, you can see there isn’t any. Right-sizing then says what each workload should request, from a week of its use.
redis-1 asks for 2 GiB of memory. Every node that’s ready has less than that left, so it waits.
redis-1 asks for 250m of CPU, which fits. It’s waiting for memory.
Every object gets a clear status, and whatever is failing comes first. You won’t scroll past 400 healthy pods to find the one that isn’t.
Health and statusStatus, values, what it made and every revision, with a diff between any two. Upgrade, or install from Artifact Hub or your computer: a dry run first, then your own helm.
Helm releasesJump to any view, object, namespace or cluster. Every view has a shortcut, and lists work with the arrow keys. Try it.
Finding thingsA workload’s pods merged in the order they wrote, each line marked with its pod. Pods that start later join in. Keep only errors, leave a pod out, or read a crashed container’s last run.
LogsInstall the Helm chart and Lumovi runs in the cluster, as a dashboard your team opens in a browser. Nobody installs anything, and everyone sees and changes only what their own permissions allow.
platformon-callSigned in with single sign-on. Lumovi acts as them.
Can see and change every namespace.
auth.mode: tokenPeople paste a token the cluster accepts, a service account’s or one from your identity provider, and the cluster checks each request made with it. Lumovi’s own service account needs no permissions.
auth.mode: oidcDex, Keycloak, Okta, Entra ID, Google or GitLab. Lumovi acts as whoever signs in, or passes their own token on when the API server already trusts the provider.
auth.mode: proxyoauth2-proxy or Pomerium signs people in and names them in a header. The chart’s network policy keeps out everything but the proxy.
Every page has an address. Send someone the pod, its logs or the release you’re looking at.
Never more than each person’s own RBAC, shells on nodes too, and readOnly: true keeps everyone from changing anything.
A small image for amd64 and arm64 that runs as non-root, has no shell and writes only to /tmp.
One Lumovi in a browser for all of your clusters. Each is summed up the way its overview would, what needs attention comes first, and everyone sees each cluster as their own RBAC there allows.
Each cluster summed up as its overview would, what needs attention first, and its labels to filter and group by. A fleet of clusters
A workload by its name or namespace, in every cluster at once, and open where it runs. Clusters in a fleet
mode: memberLumovi acts as whoever signs in, with single sign-on or a proxy, or passes their own token on to clusters that trust your identity provider.
mode: agentAn agent in the cluster dials out to Lumovi. Nothing in it listens, no firewall lets anything in, and TLS runs to the API server through it.
LUMOVI_FLEET_KUBECONFIGFrom a kubeconfig, or the Secrets Cluster API and Argo CD already keep, with each one’s labels and who may see it.
In a cluster with the Helm chart, on a VM, or on a platform like Sevalla from the image, with every setting in its environment.
Lumovi finds custom resources through discovery and shows them with the columns kubectl get prints and a status read from their conditions. Views add the columns, links and actions that matter for popular projects, and each tool the cluster runs gets a page of its own, with what’s failing first.
apiVersion: lumovi.dev/v1alpha1kind: Viewmetadata:name: cert-manager-certificatesspec:kinds:- { group: cert-manager.io, kind: Certificate }columns:- { name: Hosts, path: '.spec.dnsNames[*]' }- { name: Expires, path: .status.notAfter, type: date }status:- when:path: '.status.conditions[?(@.type=="Ready")].status'equals: 'True'health: healthylabel: Readylinks:- name: Secretkind: SecretobjectName: '{{ .spec.secretName }}'Views are data only. They read fields with JSONPath and change objects only with the patches they spell out. View format
In the desktop app, your own shell with kubectl and helm already pointed at the cluster and namespace you’re in, and port forwards to pods and services on localhost.
A shell in any container, or on any node, as root. A debug container brings tools to a pod that has none, distroless included. Each person’s RBAC decides.
Select rows with Shift-click or X, then restart, cordon, suspend or delete them together, with a retry for any that fail.
Destructive dialogs start on Cancel. Anything in a cluster named like production asks you to type the name first.
Turn changes off for one cluster, or for everyone with LUMOVI_READ_ONLY=1 (readOnly in the chart). Lumovi enforces it, not just the buttons.
Multiple files, client certificates, tokens and exec plugins like gke-gcloud-auth-plugin, aws eks get-token and kubelogin.
Lists load in chunks of 500 and are paginated and virtualized, so thousands of pods stay smooth.
A lost connection shows a banner and keeps the last data on screen instead of a blank window.
100% of every line and branch, measured across the desktop app and the server on macOS, Windows and Linux. The chart is installed on a real cluster too.
I wanted to open a cluster and know in a second whether it was healthy, and if it wasn’t, where to look first.
I work on Sevalla. It runs apps, databases and static sites on Kubernetes, and the whole point is that our users never have to think about Kubernetes. They push code, and we look after the clusters.
That means we watch a lot of clusters. Every day I’d jump between them to check on nodes, pods and capacity. The tools I had were a terminal or a wall of tables. They could tell me anything, just not at a glance.
I like to see things. A failing pod should look like a failing pod, and a node that’s out of memory should stand out before anyone has to ask. So I built the app I wanted to open every morning.
Lumovi started as a tool for my own work. It’s free and open source, because anyone who runs a cluster should have one like it.
Peter
Lumovi is free, and it stays free. Sponsoring it gives me the time to keep making it better: new views, faster lists, fewer bugs, and all the quiet work behind a good release.
Sponsor on GitHubTheir logos stand here, with a link, for everyone who comes to lumovi.dev.
$5 a month
Every bit of light helps. You keep Lumovi free, open and moving forward.
$25 a month
For people who open Lumovi every day. Your support turns into new views, faster lists and fewer bugs.
$100 a month
For teams who rely on Lumovi to keep an eye on their clusters.
$500 a month
For companies that run on Kubernetes and want Lumovi to keep shining.
Rather give once? A one-time thank you of $10 means more than you’d think, and it all goes into the app.
Push your code and Sevalla builds your app, runs it and scales it on Kubernetes, with its databases next to it. You pay for the resources you use, and you never write a manifest.
9e2b71d
Free and open source under the Apache 2.0 license, with no telemetry. Download it for your computer, or install it in your cluster for everyone on your team.
LatestVersion 1.2.0, released October 5, 2026.Release notesSHA-256 checksums Verify your download
Every installer is on the latest GitHub release.
macOS 12 or later. Signed and notarized by Apple.
Disk images (.dmg). Also as .zip for Apple silicon and Intel.
Windows 10 or later, on x64 and arm64.
Not code-signed yet. If Windows warns you, choose More info, then Run anyway.
A recent 64-bit distribution.
| Format | x64 | arm64 |
|---|---|---|
| AppImage | 152 MB | 154 MB |
| .deb | 122 MB | 118 MB |
| .rpm | 111 MB | 106 MB |
git clone https://github.com/Lumovi/Lumovi && cd Lumovi && npm ci && npm run distAny cluster on Kubernetes 1.25 or later. Then open localhost:8080 and sign in with a token.
Install Lumovi in your clusterhelm install lumovi oci://ghcr.io/lumovi/charts/lumovi \ --namespace lumovi --create-namespace kubectl port-forward --namespace lumovi service/lumovi 8080:80
Then give it an address of its own, sign people in with single sign-on, or see every setting. The same chart runs a fleet for many clusters, and an agent in private ones.
Without Kubernetes, on a machine of its own: Lumovi shows a cluster, or a fleet of them, from a kubeconfig.
Run it without Kubernetesdocker run --rm -p 8080:8080 \ -v "$PWD/kubeconfig:/kubeconfig:ro" -e KUBECONFIG=/kubeconfig \ ghcr.io/lumovi/lumovi
For linux/amd64 and arm64. Each release is signed with a build provenance attestation, which you can verify.