DEV.co
Open-Source DevOps · txn2

kubefwd

kubefwd is a command-line tool that bulk port-forwards Kubernetes services to your local machine, assigning each service a unique loopback IP and updating /etc/hosts so you can access cluster services by name (e.g., database:5432) without manual configuration. It includes an interactive TUI, auto-reconnect on pod restarts, and REST API support for programmatic control.

Source: GitHub — github.com/txn2/kubefwd
4.1k
GitHub stars
230
Forks
Go
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorytxn2/kubefwd
Ownertxn2
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars4.1k
Forks230
Open issues8
Latest releasev1.25.16 (2026-06-20)
Last updated2026-07-08
Sourcehttps://github.com/txn2/kubefwd

What kubefwd is

Written in Go, kubefwd discovers Kubernetes services via the API, establishes port forwards through kubectl, assigns unique 127.x.x.x IPs per service, and injects hostnames into /etc/hosts. It provides real-time traffic monitoring, automatic reconnection on connection loss, and optional REST API and MCP server for AI assistant integration.

Quickstart

Get the kubefwd source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/txn2/kubefwd.gitcd kubefwd# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Local Development Against Cluster Services

Eliminate environment-specific connection setup. Developers run kubefwd and their code's existing connection strings (e.g., http://api-gateway:8080) work locally as if services were in the cluster, without Docker Compose or manual port mapping.

Avoiding Port Conflicts in Development

Each service receives a unique loopback IP (127.x.x.x) instead of competing for ports on localhost:port. Multiple services can be forwarded simultaneously without manual port arbitration or conflict resolution.

Rapid Iteration on API/Microservice Changes

Engineers working on one service can connect to live versions of dependent services running in the cluster. Auto-reconnect ensures development workflows survive pod restarts and transient connection failures without manual intervention.

Implementation considerations

  • Requires kubectl to be installed and configured with cluster credentials on the developer's local machine; no centralized setup or credential injection.
  • Must run with sudo/root due to /etc/hosts modification and loopback IP binding; consider your organization's sudo policies and automation workflows.
  • Manages /etc/hosts directly—clean shutdown is important to avoid stale entries; familiarize with cleanup procedures if kubefwd crashes or is forcefully terminated.
  • Each service maps to a unique IP; verify that application code and local DNS resolvers can handle 127.x.x.x ranges and dynamic /etc/hosts updates.
  • Pod logs and TUI metrics are provided in-tool; monitor the TUI dashboard during troubleshooting rather than relying solely on separate logging aggregation.

When to avoid it — and what to weigh

  • Production Traffic or High-Throughput Scenarios — kubefwd is a development tool. It tunnels traffic through the Kubernetes API and is not designed for production workloads, high-bandwidth transfers, or persistent traffic mirroring. Use service mesh or ingress controllers for production.
  • No Sudo/Root Access Available — kubefwd requires root or sudo to modify /etc/hosts and create loopback network interfaces. Environments that restrict elevated privileges (corporate locked-down machines, certain CI/CD runners) cannot run kubefwd without workarounds.
  • Windows Subsystem for Linux (WSL) with Significant Networking Constraints — Although kubefwd supports Windows and is documented for WSL, modifying /etc/hosts and binding to loopback IPs in WSL may present platform-specific complications. Test in your WSL environment before relying on it for core workflows.
  • Teams Requiring Centralized Service Proxy or VPN-Like Access — kubefwd is single-user, per-workstation. Teams needing shared, managed network tunnels or VPN-like cluster connectivity should evaluate Telepresence or similar multi-user solutions, not kubefwd.

License & commercial use

Apache License 2.0 (Apache-2.0) is a permissive OSI-approved open-source license. It permits commercial use, distribution, modification, and private use, provided copyright and license notices are included and modifications are documented. No warranty is provided.

Apache-2.0 explicitly permits commercial use and distribution. You may use kubefwd in commercial development environments and tools without restriction, provided you retain license notices. Consider reviewing the full LICENSE file for your specific use case, but no special permission is needed.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityLow
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

kubefwd requires root/sudo access to modify /etc/hosts and bind loopback IPs, expanding the attack surface on the local machine if compromised. It establishes port-forwards through the Kubernetes API, so authentication depends on your kubeconfig credentials and RBAC policies; do not share kubeconfigs with elevated cluster access. The tool itself is covered by OpenSSF Best Practices and SLSA 3 certification, indicating attention to supply-chain and release integrity. Audit /etc/hosts after kubefwd exits to detect stale entries. No findings or exploit details are published; review OpenSSF Scorecard badge for current assessment.

Alternatives to consider

Telepresence

Multi-user intercept-based tunnel. Better for teams sharing proxies, but heavier footprint and steeper learning curve than kubefwd's bulk port-forward approach.

mirrord

Process-level network stealth. Intercepts process syscalls without modifying /etc/hosts, lighter-weight than kubefwd but less flexible for bulk service forwarding across namespaces.

kubectl port-forward

Native Kubernetes tooling. Simpler and no elevated privileges for single service, but manual port management, no auto-reconnect, and one service per invocation; kubefwd handles bulk scenarios better.

Software development agency

Build on kubefwd with DEV.co software developers

Install kubefwd today and eliminate environment-specific setup. Evaluate how bulk port forwarding with auto-reconnect fits your team's development workflow.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

kubefwd FAQ

Do I need to run kubefwd every time I start development?
Yes, unless you keep it running in a terminal. It is designed for per-session use; exit and restart when you need to change namespaces or redeploy pods. Auto-reconnect handles transient pod restarts while running.
Can kubefwd forward services across multiple clusters at the same time?
Not natively in a single invocation. You would need to run separate kubefwd instances with different kubeconfigs or contexts, or use the REST API to orchestrate multiple cluster setups. Refer to Advanced Usage documentation for multi-cluster patterns.
What happens to /etc/hosts when kubefwd crashes or is killed ungracefully?
Entries may persist. Always gracefully exit (q in TUI) or manually clean /etc/hosts. Consider backing up /etc/hosts before running kubefwd in automated workflows, or use Docker to isolate the tool.
Is kubefwd suitable for CI/CD pipelines or automated testing?
Not ideally. kubefwd is designed for interactive development. For CI/CD, consider kubectl port-forward in the background, service mesh ingress, or dedicated test fixtures. The REST API and Docker image may help in niche automation scenarios; test thoroughly.

Work with a software development agency

DEV.co helps companies turn open-source tools like kubefwd 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 streamline your Kubernetes local development?

Install kubefwd today and eliminate environment-specific setup. Evaluate how bulk port forwarding with auto-reconnect fits your team's development workflow.