kftray and kftui: a port-forward manager 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 Rust-based Kubernetes port-forward manager with a desktop tray app and a terminal UI that share the same config files. It reconnects forwards when pods move, adds UDP and HTTP inspection, and can expose local services through a cluster.
- Who is it for?
- Adopt kftray or kftui if you keep several port forwards open across restarts and want them managed from one place, and if GPL-3.0 fits your use. Skip it if you need only an occasional single forward, or if you cannot accept a tool that watches pods and can write hosts entries.
- 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 last received commits 5 days ago.
- 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 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The failure mode kftray was built around
Plain kubectl port-forward is a foreground process tied to one pod. When that pod is rescheduled, the tunnel dies and the terminal shows an error. Anyone running more than two or three forwards ends up with a wall of terminal windows and a habit of restarting them by hand. kftray and kftui target exactly that: developers and operators who keep long-lived forwards to services inside a cluster and want them to come back on their own. The README frames the project as a response to kubectl port-forward falling apart "when pods restart or connections drop", and lists the same complaints: no automatic reconnection, one terminal per forward, no UDP, and no way to see the HTTP traffic crossing the tunnel. The intended audience is not someone who forwards a port once a month. It is someone who treats a set of forwards as part of their daily environment.
How the reconnection and the proxy relay actually work
Both front ends share one Rust backend and the same configuration files, which is why kftray and kftui can be used interchangeably on the same machine. The reconnection mechanism is built on the Kubernetes watch API: the tool subscribes to pod lifecycle events, notices when a pod it is forwarding to disappears or is replaced, and re-establishes the forward against a healthy pod. The feature matrix describes this as pod health tracking plus auto-reconnection, and adds network recovery for the case where the laptop sleeps or the network drops.
TCP and UDP are not handled the same way. UDP cannot be carried by kubectl-style port forwarding, so the project routes it through a proxy relay running inside the cluster, and the same relay is what makes HTTP traffic inspection possible. That is a meaningful architectural choice: the relay is something you deploy, not something that exists by default, and the examples directory contains separate config files for pod-tcp, service-tcp, proxy-tcp, proxy-udp and HTTP log scenarios. The HTTP logging path sees request and response data, which is why the README's own note warns that logs and replay can expose sensitive data and should be opt-in. The reverse tunnel feature, described as ngrok-like, uses the same cluster-side machinery to publish a local service outward, with TLS termination and auto SSL certificate generation listed in the matrix.
Installing kftui and starting a first forward
The README points to the downloads page for the desktop app, and the repository documents three routes for the terminal UI: Homebrew, Cargo, and distribution packages. The Linux packages are published for Debian, Ubuntu, Fedora and openSUSE through the openSUSE Build Service, so the repository is added once and updates arrive with normal system upgrades. The README shows the Debian and Ubuntu setup, with the distribution name swapped for Debian_13, Ubuntu_22.04, Ubuntu_24.04 or Ubuntu_26.04 as needed. The snippet the README gives is only the first step:
sudo mkdir -p /etc/The README truncates the rest, so follow the repository's INSTALL document for the complete key and repository lines rather than guessing at them. For the terminal UI without a package manager, the crates.io badge points at the kftui crate, which means the Cargo route is available.
Once installed, the first real task is defining a forward rather than typing one. Configurations are stored as files, and the examples directory is the fastest way to see the shape of one. Read examples/pod-tcp.json in the repository for the exact field names before writing your own, since the example files are the reference. From the terminal UI you then select the entry and start it. What you should see is the forward listed as running with the pod it is currently attached to; when that pod is replaced, the entry should return to running without you restarting anything. If you prefer the desktop app, the same config file is read by kftray, and the tray icon gives quick access to start and stop entries.
Where the design costs you something
The auto-reconnection depends on watching the Kubernetes API continuously, which means the tool holds credentials and talks to the cluster directly. That is the point, since the README advertises "No kubectl needed", but it also means the tool is a long-running client with cluster access rather than a short-lived command you invoke and forget. On a locked-down cluster, a tool that watches pods and can deploy a proxy relay may need permissions that kubectl port-forward alone would not.
Hosts file management is the second cost. The matrix lists automatic /etc/hosts updates, and the project's own note says those updates may require admin privileges and vary by operating system. A tool that edits /etc/hosts on your behalf is convenient until you want to know what it wrote there. The HTTP inspection feature carries a similar caveat from the README itself: request and response bodies can contain tokens and personal data, so leaving logging on by default in a shared environment is a bad idea. Finally, the reverse tunnel and public exposure features turn a local development tool into something that publishes services, and the README does not document rollback or teardown semantics for those tunnels. If you need a guarantee about what is left behind after an expose session ends, the documentation is silent and you should test it yourself before relying on it.
kftray versus kubefwd and Kubetui
The most common comparison for kftray is kubefwd, which also manages Kubernetes port forwards. The difference in approach is the interface and the scope. kubefwd is a command-line service-forwarding tool; kftray and kftui are applications with persistent configuration, a desktop tray or a terminal UI, and features that go past forwarding, such as UDP through a cluster-side relay, HTTP traffic logs, request replay in the terminal UI, and reverse tunnels for exposing local services. If your need is a script that forwards a list of services and exits, kubefwd-style tools fit that model more directly. If your need is a set of forwards you keep running and occasionally debug, the config-file plus interface model is the reason to pick kftray.
Kubetui is a terminal UI for Kubernetes, and the overlap is the terminal presentation rather than the forwarding engine. kftui is specifically a port-forward manager with the reconnection and relay features above; a general cluster TUI covers browsing and inspecting resources. They are not substitutes. The honest summary is that kftray competes on persistence and on features kubectl does not have, not on being a thinner wrapper around kubectl.
Maintenance, licensing and the cost of upgrading
The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.27.32 on 2026-09-09, v0.27.31 the day before, and v0.27.30 back on 2026-05-13. That pattern suggests a project that ships often, with a gap in the middle of 2026 and a burst in September. For an operator, frequent patch releases mean the upgrade path is short but not free: the desktop app is a Tauri application, the terminal UI is published on crates.io as kftui, and the Linux packages come from the openSUSE Build Service, so whichever route you chose determines how you upgrade. Package-manager users get updates with the system upgrade; Cargo users reinstall; the desktop app is a download. Configuration files are shared between the two front ends, which is a practical benefit during upgrades, since a config written for one front end is read by the other.
The licence is GPL-3.0. For internal developer tooling that is usually unproblematic, but GPL-3.0 is a copyleft licence, and if you intend to bundle kftray or its crates into a distributed product, the obligations are worth reading in full rather than assuming. This is a description of the licence identifier, not legal advice. The repository also carries SECURITY.md, an OpenSSF Scorecard badge and an OpenSSF Best Practices badge, which indicate the project tracks security practices, though a badge is not an audit.
Editorial conclusion
Adopt kftray or kftui if you keep several port forwards open across restarts and want them managed from one place, and if GPL-3.0 fits your use. Skip it if you need only an occasional single forward, or if you cannot accept a tool that watches pods and can write hosts entries. Verify first that your kubeconfig context is the one you intend, because the tools act directly on the Kubernetes API rather than through kubectl.
Frequently asked questions
What port does kubectl use?
The repository does not document kubectl's internal port behaviour. What it does document is that kftray and kftui do not need kubectl at all, because they integrate with the Kubernetes API directly, and that UDP traffic is carried through a proxy relay inside the cluster.
How do I stop a kubectl port forward?
The repository does not cover stopping kubectl port-forward. In kftray and kftui, forwards are entries you start and stop from the interface, and the feature matrix also lists port-forward timeouts that auto-close a forward after a time limit.
What is the difference between kftray and kftui?
kftray is the desktop application with system tray integration, and kftui is the terminal UI. Both share the same Rust backend and the same configuration files, so the feature matrix is nearly identical. The tray integration is desktop-only, and request replay for HTTP debugging is listed for the terminal UI only.
Can kftray expose a local service publicly?
The feature matrix lists exposing local services as a reverse tunnel, described as ngrok-like, available in both front ends. The README also lists TLS termination and automatic SSL certificate generation for port forwards. Rollback and teardown behaviour for exposed tunnels is not documented in the README.
Does kftray need kubectl installed?
No. The feature matrix lists "No kubectl needed" for both front ends, because the tools integrate with the Kubernetes API directly. That also means they hold cluster credentials and watch pod lifecycle events themselves.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hcavarsan-kftray)