DevOpsPadDownload

DevOpsPad vs Lens - two desktop apps for Kubernetes

· Comparisons

The DevOpsPad resource inspector for a Pod, with Overview, Events, Logs and JSON tabs and a containers table showing state and restarts.
The DevOpsPad resource inspector for a Pod, with Overview, Events, Logs and JSON tabs and a containers table showing state and restarts.

Lens is a Kubernetes IDE: it manages clusters across clouds, edits resources, opens terminals into Pods, installs Helm charts and graphs metrics. DevOpsPad is smaller in Kubernetes scope and different in shape. Its cluster explorer is read-only, it sits next to MySQL, Redis, MongoDB, Kafka and ClickHouse in the same window, and the only cluster writes are reviewed Deployment releases from the Infra console. For managing many managed-cloud clusters, Lens is the stronger tool. For a few K3s machines behind SSH, plus the databases they serve, DevOpsPad fits better.

At a glance

Lens Desktop DevOpsPad
Scope Kubernetes Kubernetes/K3s plus MySQL, Redis, MongoDB, Kafka, ClickHouse
Editing resources Yes No in the explorer; Infra console releases, scales, restarts and rolls back existing Deployments after a dry-run plan
Pod shell / exec Yes No
Logs Streaming Snapshots up to 2,000 lines / 256 KiB, including the previous container instance
Helm Yes No
Metrics Charts (with a metrics stack) CPU/memory snapshots from metrics-server in the Infra console
Exec auth plugins (EKS, GKE, AKS helpers) Yes Not yet; token and client certificate only
Account Lens ID required to activate No account
Platforms Windows, macOS, Linux macOS on Apple silicon (signed); others from source

Lens product details are from Mirantis’ Lens documentation; editions and features change, so check there.

When to choose Lens

  • You manage clusters, not just inspect them. Editing YAML in place, deleting stuck Pods, opening a shell, port-forwarding and installing Helm charts are everyday Lens actions. None of them exist in DevOpsPad.
  • You use EKS, GKE or AKS with exec credentials. Most managed-cloud kubeconfigs call a credential helper. DevOpsPad rejects exec-based authentication in this version.
  • You want live logs and metrics charts. Lens streams logs and can chart metrics. DevOpsPad takes log snapshots and reads point-in-time CPU and memory.
  • You work on Windows or Linux. Lens supports both.
  • Your team buys commercial support. Lens has paid tiers with support from Mirantis.

When to choose DevOpsPad

  • Your clusters sit behind SSH. Small K3s setups often expose the API only on 127.0.0.1:6443. DevOpsPad dials the kubeconfig’s API server from the SSH host, keeps the kubeconfig’s CA and TLS server name, and verifies the SSH host key. No ssh -L running in a terminal.
  • You want to look without being able to break anything. The explorer reads; it does not delete or edit. Your RBAC still applies, and each section explains which permission it needs. See RBAC permissions.
  • Your incidents cross into data. The same Explorer holds the MySQL, Redis and Kafka connections the service depends on, so checking a queue’s partition leaders after a Pod restart is one click, not another app.
  • You want releases to be reviewable. The Infra console’s writes start with a server-side dry-run, show you current and target image, take a per-Deployment Lease, check the resource version again, wait for the rollout and keep a local record. Read release an image.
  • You do not want an account. DevOpsPad has no login and no hosted backend. Lens requires a Lens ID, including for its free personal use.

Events and logs, side by side

Both tools show events and logs; the details differ. DevOpsPad matches events by the resource UID, so a Pod that was recreated with the same name does not show the old Pod’s events. Its log view lets you pick application, init or ephemeral containers and the previous instance, which is usually what you need after a CrashLoopBackOff. It does not follow the stream; refresh to fetch a new snapshot.

Accounts and network access

DevOpsPad has no account, no telemetry backend and no hosted service. It talks to the endpoints you configure, to the AI provider only if you set one up, and to the GitHub releases API to check for a newer version. Connection metadata stays in a local file and secrets in the OS keychain. Lens activation uses a Lens ID and Mirantis services; Mirantis documents what is and is not synced in its own FAQ. If your environment has strict rules about which tools may hold a kubeconfig, that difference may decide the question before features do.

Using both

If you already use Lens for cluster administration, DevOpsPad can sit next to it as the read-only and data-side view, and as the place where Deployment releases go through a plan. Both read the same kubeconfig files; DevOpsPad never modifies them. Start with kubeconfig contexts, or see the Kubernetes connector.