DevOpsPadDownload

A K3s client that reaches 127.0.0.1:6443 through SSH

Connect to K3s with its kubeconfig over SSH, browse resources, events and Pod logs, then release, scale and roll back Deployments in the Infra console.

Download for macOSRead the guide

Transport: client-go via kubeconfig, the same adapter as Kubernetes (API port 6443 by default)

The Logs tab of the resource inspector with a container selector, tail lines, a Previous instance checkbox and a timestamped log snapshot.
The Logs tab of the resource inspector with a container selector, tail lines, a Previous instance checkbox and a timestamped log snapshot.

What you can do today

  • Contexts, namespaces and resource lists from the K3s kubeconfig
  • Resource details, UID-matched events and Pod log snapshots
  • SSH tunnels that dial the API server from the K3s host itself
  • Infra console workflows on existing Deployments - image release, scale, restart and rollback after a dry-run plan
  • Cluster nodes with Ready state, roles, IPs, CPU, memory and versions in the Infra console
  • CPU and memory snapshots from the bundled metrics-server

Not supported yet

  • Exec-based authentication plugins
  • Live log streaming and kubectl exec
  • Creating or deleting workloads, and changes to StatefulSets or DaemonSets

Built for the clusters small teams actually run

K3s is a common choice for a few machines: a single binary, a bundled metrics-server, and a kubeconfig at /etc/rancher/k3s/k3s.yaml that points at https://127.0.0.1:6443. That last part is what makes remote access awkward. You either expose the API port, edit the server address, or keep an ssh -L running in a terminal.

DevOpsPad handles it with its SSH tunnel. Copy the kubeconfig to your Mac, choose it in a K3s connection, and enable Connect through SSH tunnel with the K3s host as the SSH server. The API address in the kubeconfig is dialed from the SSH host, so 127.0.0.1 means the K3s server itself. TLS still verifies against the kubeconfig’s CA and server name. See the SSH tunnel overview.

Browse and debug

Everything in the Kubernetes connector works on K3s: contexts and namespaces, get pods style lists, the resource inspector, events matched by UID, and Pod log snapshots with the previous container instance. Access is read-only and limited by the RBAC of the credentials in your kubeconfig.

Release from the Infra console

The Infra console turns a K3s connection into an application view. Map workloads to environments with the K3s onboarding wizard, register images by immutable digest, then release a new image to an existing Deployment. Every write starts with a server-side dry-run plan you review, takes a Kubernetes Lease so two people cannot release the same Deployment at once, checks the resource version again, waits for the rollout and writes a local record. Scale, restart and rollback use the same path. Read release an image for the full flow, or safe releases for the design.

Limits

Exec-based authentication, live log streaming and kubectl exec are not available. The release engine changes existing Deployments only; StatefulSets and DaemonSets are view-only, and creating or deleting workloads still needs your usual tooling.

Help articles

Frequently asked questions

What is the difference between the K3s and Kubernetes connectors?

They use the same client-go adapter and support the same resources. K3s is a separate connection type so small clusters are easy to recognize, and it is the default type when you add a cluster from the Infra console's K3s onboarding.

How do I connect to a K3s server that only listens on localhost?

Copy the K3s kubeconfig to your Mac and enable the SSH tunnel to the K3s host. The 127.0.0.1:6443 address in the kubeconfig is then dialed from the SSH server, so the API port never has to be exposed.

Do I need to install anything on the K3s host?

No. DevOpsPad uses the Kubernetes API and SSH. Nothing is installed on the nodes and no controller runs in the cluster.