kftray
kftray is a Kubernetes port-forwarding manager (desktop and terminal UI) that automatically reconnects when pods restart, handles TCP/UDP traffic, and supports reverse tunneling to expose local services publicly. Built in Rust with GPL-3.0 licensing, it replaces fragile kubectl port-forward workflows for development teams.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | hcavarsan/kftray |
| Owner | hcavarsan |
| Primary language | Rust |
| License | GPL-3.0 — OSI-approved |
| Stars | 1.5k |
| Forks | 73 |
| Open issues | 27 |
| Latest release | v0.27.30 (2026-05-13) |
| Last updated | 2026-07-08 |
| Source | https://github.com/hcavarsan/kftray |
What kftray is
Desktop (Tauri-based GUI + system tray) and terminal (ratatui TUI) interfaces sharing a Rust backend. Monitors pod lifecycle via Kubernetes watch API, auto-reconnects on pod churn, supports multi-hop proxy routing through cluster relay, HTTP traffic inspection, and reverse tunnel exposure (ngrok-like). Configuration stored as JSON, synced via Git or filesystem.
Get the kftray source
Clone the repository and explore it locally.
git clone https://github.com/hcavarsan/kftray.gitcd kftray# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- GPL-3.0 copyleft license demands source availability if distributed; internal use only avoids disclosure, but commercial redistribution requires legal review.
- Requires Kubernetes API access (kubeconfig) and optional in-cluster proxy relay for TCP/UDP support; review RBAC permissions and network policies.
- Shared JSON config format enables team collaboration via Git but demands change-management discipline to avoid port/service collisions.
- HTTP traffic logging is opt-in but can capture sensitive headers/payloads; implement sanitization and access controls if enabled in shared environments.
- Hosts file management requires OS-level privileges (admin/sudo) and may conflict with other DNS tools; test on target platforms before rollout.
When to avoid it — and what to weigh
- Strict Commercial / Proprietary Use Without Modification — GPL-3.0 requires source disclosure if distributed; derivative works must be GPL-3.0. Commercial use requires review of GPL copyleft obligations.
- Ephemeral / Immutable Infrastructure Only — Designed for persistent pod management. Not suited for one-off, stateless port-forward jobs; kubectl port-forward suffices for those.
- Air-Gapped Environments Without Git Sync Setup — Configuration sharing relies on GitHub or filesystem. Offline-first deployment requires pre-staging JSON configs manually.
- Production Security-Critical Ingress (Unvetted TLS Handling) — HTTP traffic inspection and auto-SSL features may expose sensitive data or misconfigure certificates; requires careful auditing before prod use.
License & commercial use
Licensed under GPL-3.0 (GNU General Public License v3.0). This is a copyleft open-source license that requires source code disclosure and mandates GPL-3.0 for any derivative works or distributed binaries.
GPL-3.0 permits internal commercial use without restriction. However, if you distribute kftray (modified or unmodified) as part of a commercial product or service, you must disclose source code and license the distribution under GPL-3.0. Requires legal review for cloud SaaS, repackaging, or embedded commercial use. Using unmodified binaries from GitHub is low-risk; modifications or bundling require compliance.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Good |
| Assessment confidence | High |
HTTP traffic inspection logs can expose authentication headers, PII, and API keys; must opt-in and sanitize. TLS termination and auto-SSL generation require cert-manager trust chain validation. Requires direct Kubernetes API access via kubeconfig; review RBAC/ServiceAccount permissions carefully. In-cluster proxy relay can become attack surface if exposed; network policies and ingress authentication critical. No formal security audit data provided. GPL-3.0 license audit required for commercial use.
Alternatives to consider
kubectl port-forward (native)
Zero-dependency baseline; sufficient for one-off tasks but breaks on pod churn and lacks UDP, TLS, or traffic inspection.
Telepresence (datawire)
Full-stack intercept proxy with service mesh integrations; heavier footprint but handles pod lifecycle and DNS injection. Permissive Apache 2.0 license.
ngrok / Cloudflare Tunnel
Hosted reverse-tunnel services for public exposure; no cluster setup needed but closed-source, external dependency, and ongoing costs.
Build on kftray with DEV.co software developers
Evaluate kftray for your development team. Check the GPL-3.0 license terms, review proxy relay architecture, and test auto-reconnect in your staging cluster before rollout.
Talk to DEV.coRelated on DEV.co
Explore the category and the services that help you build with it.
kftray FAQ
Can I use kftray in a commercial product?
Does kftray replace kubectl port-forward entirely?
What Kubernetes versions are supported?
Is the in-cluster proxy relay required?
Software developers & web developers for hire
DEV.co helps companies turn open-source tools like kftray into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source devops stack.
Ready to Simplify Kubernetes Port Forwarding?
Evaluate kftray for your development team. Check the GPL-3.0 license terms, review proxy relay architecture, and test auto-reconnect in your staging cluster before rollout.