FreeLens: What It Is, How to Install It, and Whether You Should Trust It (2026)

FreeLens is a free, MIT-licensed desktop IDE for Kubernetes. It is the community fork of OpenLens — the open-source core of Lens Desktop — created after Mirantis stopped publishing OpenLens binaries and moved Lens behind a mandatory account and a commercial licence. It runs on macOS, Windows and Linux, reads your existing kubeconfig, and gives you the cluster overview, workloads, logs, terminal, Helm and metrics views that made Lens popular in the first place, without the sign-in screen.

If you searched for “freelens” you probably want one of four things: to know whether it is legitimate, to install it, to see what it can do, or to decide between it and the alternatives. This page covers all four in that order. The long-form comparison with OpenLens and Lens lives in FreeLens vs OpenLens vs Lens, and the full extension catalogue in FreeLens Extensions in 2026 — both are linked from the relevant sections rather than repeated here.

What Is FreeLens?

Three facts cover it. FreeLens is a fork of OpenLens, so it is the same Electron application, the same UI and the same extension API that Lens users have known since 2020, continued under the MIT licence by the freelensapp organisation on GitHub. It is maintained by a core team of four people plus a release engineering team, and it ships a new release roughly every month — the current version is v1.10.3 (7 July 2026), built on Electron 41 and Node.js 24, and bundling kubectl 1.36.2 and Helm 4.2.2 so you do not need either binary installed locally. And it is not a toy: the repository sits at about 5,600 GitHub stars, with 330 forks and close to 2,000 commits on the main branch.

The word “IDE” is a Lens-era marketing term. FreeLens does not edit your application code; it is a cluster client. What it replaces is the loop of kubectl get, kubectl describe, kubectl logs -f and kubectl exec across several contexts, plus the Helm CLI for release management, plus a Grafana tab for basic resource metrics. If that loop is most of your day, FreeLens is worth ten minutes to install.

How to Install FreeLens

FreeLens publishes installers for every platform in GitHub Releases, and packages for the usual package managers. All commands below come from the project README and were checked against v1.10.3.

macOS (12 or later, Apple Silicon and Intel)

brew install --cask freelens

The cask picks the right architecture. If you do not use Homebrew, the release page has both a PKG and a DMG for arm64 and amd64.

Windows (10 or later, x64 and ARM64)

winget install Freelensapp.Freelens

Or with Scoop:

scoop bucket add extras
scoop install freelens

There are also NSIS .exe, MSI and portable builds on the release page. Since v1.10.2 the Windows binaries are code-signed, which ended the long-running problem of antivirus products flagging the installer as a false positive. If your endpoint tooling still complains, make sure you are on 1.10.2 or newer before opening a ticket.

Linux (glibc 2.34 or later — Debian 12, Ubuntu 22.04, Fedora 35 and newer)

The APT repository is the cleanest option on Debian and Ubuntu because it gives you upgrades through apt:

curl -L https://raw.githubusercontent.com/freelensapp/freelens/refs/heads/main/freelens/build/apt/freelens.asc | sudo tee /etc/apt/keyrings/freelens.asc
curl -L https://raw.githubusercontent.com/freelensapp/freelens/refs/heads/main/freelens/build/apt/freelens.sources | sudo tee /etc/apt/sources.list.d/freelens.sources
sudo apt update
sudo apt install freelens

Flatpak, if you prefer the sandboxed route:

flatpak install flathub app.freelens.Freelens
flatpak run app.freelens.Freelens

Snap:

snap install freelens --classic

Arch users have freelens-bin in the AUR, and there are .deb, .rpm and AppImage downloads for both amd64 and arm64. The AppImage needs libfuse2 and zlib1g-dev installed first, which is the usual AppImage story rather than anything FreeLens-specific.

Requirements

FreeLens supports clusters running Kubernetes 1.22 or later. For older clusters it falls back to the bundled kubectl, and you can point it at a different kubectl binary in Preferences if you need version-matched behaviour for something ancient. It reads ~/.kube/config and any additional kubeconfig files you add, so there is no import step: if kubectl works from your terminal, the same contexts appear in FreeLens.

What FreeLens Ships With

The base application covers most of what teams used Lens for, and the last three minor releases have added the features people most often asked for. Version numbers are given so you can check what your installed build has.

• Cluster catalogue and contexts. Every context from your kubeconfig, with per-cluster settings, icons and Prometheus configuration. Multiple clusters open in tabs.
• Workloads, config, network, storage and RBAC views. The full resource browser, with a YAML editor, describe-style detail panes and event streams. v1.10.3 added ValidatingAdmissionPolicy resources, v1.10.0 added the scheduler name in pod details and the cloud provider ID in node details.
• Logs. Multi-container log viewer with follow, search, timestamps and, since v1.9.0, line wrapping. v1.10.3 respects the kubectl.kubernetes.io/default-container annotation, so the right container is selected first on multi-container pods.
• Terminal and exec. A built-in terminal preloaded with the bundled kubectl and Helm and pointed at the active context, plus one-click shell into any container.
• Port-forwarding from the UI, persisted per cluster.
• Helm. Chart repositories, releases, values editing, upgrade and rollback, driven by the bundled Helm 4.2.x — no local Helm install required.
• Metrics. CPU, memory, network and filesystem charts fed by an in-cluster Prometheus. v1.9.0 added OpenShift’s Prometheus with bearer-token authentication and a GET/POST switch for the query endpoint; v1.10.0 added a time-range selector for the charts.
• In-place pod resize (v1.9.0), using the Kubernetes in-place resource resize feature where the cluster supports it.
• Proxy support, including SOCKS5 as of v1.10.3, for clusters reachable only through a bastion.
• Theme sync with the OS (default since v1.9.0), plus the classic light and dark themes.

What it does not ship with: any kind of server component, multi-user access or shared views. FreeLens is a desktop client whose permissions are exactly the permissions of your kubeconfig. If you need one shared UI whose access is governed by cluster RBAC, that is the Headlamp use case, covered below.

FreeLens Extensions

Extensions are where FreeLens pulls ahead of most alternatives, because it inherited the Lens extension API and the community ported the popular OpenLens extensions across. Installation takes thirty seconds: open the Extensions page (Cmd+Shift+E on macOS, Ctrl+Shift+E elsewhere), paste the npm package name — the scoped name in full — and press Install. FreeLens pulls the package from the npm registry and unpacks it; there is no separate marketplace to browse, so the package name is what matters. Extensions also expose a freelens://app/extensions/install/... deep link you can click from a README.

The ones worth knowing about:

Two caveats. Extensions that render CRDs show empty views on clusters where the CRDs are not installed, which surprises people who install everything at once. And the old freelens-node-pod-menu package is deprecated — its functionality moved into the core app — so if a tutorial tells you to install it, skip that step. The complete list, including credential explorers and AI-assistant extensions, is in FreeLens Extensions in 2026.

FreeLens vs OpenLens vs Lens (Short Version)

The lineage is simple. Lens Desktop is the commercial product from Mirantis; it requires a Lens ID account and a paid subscription for business use. OpenLens was the open-source core that community members built into a full application; Mirantis removed the built-in pod menus in 2022, stopped publishing binaries, and the community builds eventually stalled on old Electron versions. FreeLens forked OpenLens in late 2024 to keep that codebase alive under a permissive licence with a modern toolchain, and it is now the only one of the three that is both free and maintained.

The honest recommendation: if you are still on OpenLens, move to FreeLens today, because you are running an unpatched Electron browser with cluster credentials in it. If you are paying for Lens and happy, nothing forces you off it. The full argument, including the licensing timeline and the features Lens keeps exclusive, is in FreeLens vs OpenLens vs Lens.

The other comparison people ask about is Headlamp, the CNCF-hosted UI that replaced the archived Kubernetes Dashboard. Headlamp can run as a desktop app like FreeLens, but its distinctive mode is in-cluster: one shared web UI whose permissions come from Kubernetes RBAC rather than from each engineer’s laptop. For a team that wants a governed, shared view, Headlamp is the stronger institutional choice; for an individual who wants the best desktop workflow and the richest extension catalogue, FreeLens still wins. Many organisations run both, and Headlamp vs FreeLens vs Lens has the decision framework.

Who Maintains FreeLens, and What Is the Risk?

This is the question that decides whether a platform team standardises on a tool, so it deserves a straight answer rather than a badge.

FreeLens is governed by a named core team — a founder who handles project management, community and the extension ecosystem, and three maintainers covering architecture and releases, UI and documentation, and AI-related features — plus a three-person release engineering team that reviews pull requests and cuts releases. That is small, but it is not one person, and the roles are published in the README. Releases have been steady: v1.9.0 in May 2026, v1.10.0 in June, three patch releases through 7 July, with nightly builds available in a separate repository for people who want to test ahead of a release.

Funding is donations plus a bounty model through BountyHub: anyone can put money on a specific issue, and a contributor who lands the pull request collects it. The README is explicit that features are decided by the community and overseen by the core team, not by whoever pays. There is no company behind FreeLens, which cuts both ways. Nobody can relicense it or put a login wall in front of it — the thing that happened to Lens — but there is also no commercial support contract to buy, and if the core team lost interest the project would slow down the way OpenLens did.

The mitigations are real, though. The codebase is MIT and the build is reproducible from the repository, so a fork is always possible; the extension API is stable and shared with the Lens lineage; and the security-relevant dependencies — Electron, Node, kubectl, Helm — are tracked within weeks of upstream, which is more than most desktop tools manage. For an individual engineer the risk is negligible. For an organisation, treat FreeLens the way you would any community-maintained developer tool: pin a version, watch the release cadence, and keep the exit (Headlamp, or plain kubectl) in mind.

Migrating From OpenLens or Lens

Because FreeLens is the same codebase, migration is mostly nothing. Your kubeconfig is read directly, so every cluster and context appears without an import. Cluster-level settings — Prometheus endpoints, icons, namespace preferences — need to be set again, because FreeLens keeps its own configuration directory rather than reading OpenLens’s, and that is deliberate: it lets you run both side by side while you switch.

Extensions are the one thing to check. Most popular OpenLens extensions have been ported and republished under new npm names, typically @freelensapp/...; the old Lens Marketplace names will not install. Look each of yours up in the catalogue linked above before uninstalling OpenLens. Lens Desktop’s account-bound features — Lens Spaces, Lens Teamwork and the cloud-synced catalogue — have no equivalent in FreeLens, so if your team relies on them you are choosing between paying for Lens and changing your workflow, not between two clients.

Frequently Asked Questions

Conclusion

FreeLens is the answer to a specific question: how do I keep the Lens workflow without the Lens account? It is free, it is current, it is maintained by a small but real team with a public release cadence, and it installs in one command on every platform. Its limits are the limits of any desktop client — no shared views, no server-side RBAC — and if those matter, Headlamp exists. For everyone else, and especially for anyone still opening OpenLens, install it and move on.