kftray and kftui: Kubernetes port forwarding that survives pod restarts
kubectl port-forward manager and reverse tunnel (ngrok-like) for exposing local services publicly, with TLS termination, HTTP traffic inspection, UDP forwarding, multi-hop proxy routing through k8s clusters, stateful config via filesystem or git - GUI and TUI available
At a glance
- What is it?
- kftray is a desktop tray app and kftui is a terminal UI that share one Rust backend for managing kubectl port-forwards, watching pods and reconnecting automatically, with TCP/UDP relay, HTTP inspection and reverse tunnelling. The trade-off is breadth: a GPL-3.0 tool that does more than kubectl, and asks you to trust it with cluster credentials and local hosts-file edits.
- Who is it for?
- Adopt kftray if you keep long-lived forwards to development clusters and are tired of restarting kubectl after every rollout; adopt kftui if you want the same backend without a tray process. Do not adopt it for production traffic paths, for shared machines where an auto-edited /etc/hosts is unacceptable, or if GPL-3.0 distribution terms conflict with how you ship internal tooling.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap kftray targets: kubectl port-forward has no memory
kubectl port-forward binds a local port to a pod and forgets about it. When that pod is rescheduled, the tunnel dies and the command exits. The README lists this first among the problems it addresses: connections break on restart, there is no automatic reconnection, multiple forwards mean multiple terminals, UDP is unsupported, and HTTP traffic through the tunnel cannot be inspected. kftray and kftui are aimed at the developer who keeps half a dozen forwards open against a development or staging cluster all day, and at teams who want those forward definitions stored somewhere shareable rather than retyped. The audience is explicitly the inner-loop developer, not the platform team building ingress. One detail worth noting from the feature matrix: HTTP request replay exists only in kftui, while system tray integration exists only in kftray. The two front ends are not interchangeable.
How the reconnection actually works: watch API plus a cluster-side relay
The README states that both tools use the Kubernetes watch API to detect when pods come and go, then reconnect forwards without manual intervention. That is the core mechanism, and it is why the tools talk to the Kubernetes API directly rather than shelling out to kubectl. The second mechanism is a proxy relay running in the cluster, which is what makes TCP and UDP forwarding possible; plain kubectl port-forward is TCP-only. HTTP traffic logging and the reverse-tunnel feature (described as ngrok-like, exposing local services publicly with TLS termination) sit on top of that relay path. Configuration is stateful, stored either on the filesystem or in git, which is what enables the GitHub sync and team-sharing features listed in the matrix. The README does not document the relay's deployment model, its resource footprint, or how it is cleaned up, so treat that as an open question to resolve from the source tree before relying on it.
Getting it installed: packages, Cargo, and the kubeconfig you point it at
The README points to a downloads page for prebuilt desktop and terminal binaries, and documents a Homebrew or Cargo install path for kftui. On Linux, every release publishes kftray and kftui packages for Debian, Ubuntu, Fedora and openSUSE through the openSUSE Build Service. The README gives the shape of that setup: add the repository once, then install with your package manager, and updates arrive with the regular system upgrade. For Debian and Ubuntu you substitute the distribution name in the repository URL (Debian_12, Debian_13, Ubuntu_22.04, Ubuntu_24.04, Ubuntu_26.04 are the listed options). The README excerpt cuts off mid-command, so check the current install docs rather than copying a partial snippet. Both front ends accept a custom kubeconfig path, which matters if you juggle several clusters, and both can auto-import services discovered through Kubernetes annotations, which is the mechanism behind keeping forward definitions in sync across a team.
Where it stops being the right tool
Port forwarding is a debugging convenience, and kftray does not change that. It is not an ingress controller, a service mesh, or a replacement for a proper load balancer; the reverse-tunnel feature exposes a local service, but the README gives no guidance on authentication, rate limiting or exposure risk beyond a note that HTTP logs and replay can leak sensitive data and should be opt-in and sanitised. The hosts-file management feature is a second sharp edge: the README's own footnote says updating /etc/hosts may require admin privileges and varies by operating system. On a managed laptop or a shared build host, a tool that silently rewrites that file is a policy problem, not a feature. The third constraint is licensing. kftray is GPL-3.0, which is copyleft; if you redistribute it inside a product, or modify and ship it, the obligations differ from a permissive tool. That is a question for your legal team, not something to settle from a README.
Compared with kubectl port-forward and with a plain SSH tunnel
The honest comparison is not against another GUI. It is against the two things engineers already use. Plain kubectl port-forward has no daemon, no relay, no config file and no licence question; it is one process per forward and it fails loudly when the pod moves. kftray trades that simplicity for a persistent watcher, a cluster-side relay and stored configuration, which is a real gain if you restart forwards often and a real cost if you do not. An SSH tunnel through a bastion is the other alternative: it survives pod restarts by construction because it targets the node or service, not a pod, but it gives you no pod-level health visibility, no UDP path defined the way kftray defines one, and no HTTP inspection. The difference in approach is that kftray stays inside the Kubernetes API and reacts to pod lifecycle events, while an SSH tunnel is indifferent to what Kubernetes is doing. Pick based on whether pod churn is the thing that hurts you.
Maintenance cost and release cadence
The release history shows v0.27.32 and v0.27.31 published one day apart in September 2026, with v0.27.30 roughly four months earlier. That pattern suggests bursts of activity rather than a steady drip, and it is worth watching if you depend on the tool daily. The shared Rust backend between kftray and kftui is the main maintenance argument in its favour: one configuration format, one reconnection implementation, two front ends, so a fix in the backend reaches both. The cost side is the relay and the hosts-file edits. A cluster-side component means something to deploy and clean up, and automatic /etc/hosts changes mean your local environment drifts in ways that are easy to forget when a forward is deleted. Neither is documented in enough depth here to estimate operational effort, which is itself a finding.
Editorial conclusion
Adopt kftray if you keep long-lived forwards to development clusters and are tired of restarting kubectl after every rollout; adopt kftui if you want the same backend without a tray process. Do not adopt it for production traffic paths, for shared machines where an auto-edited /etc/hosts is unacceptable, or if GPL-3.0 distribution terms conflict with how you ship internal tooling. Before trusting it, verify two things in your own cluster: that its watch-based reconnection behaves under your RBAC restrictions, and that the reverse-tunnel and auto-SSL paths are ones your network policy actually permits.
Community notes