kubefwd (Kube Forward) is an Apache-2.0 licensed, Go-based command-line utility that bulk port forwards Kubernetes services to a local workstation, giving each service its own unique 127.x.x.x loopback address and a matching /etc/hosts entry so that locally running code can reach cluster services by their in-cluster names, and it is aimed at developers who build and test against a Kubernetes development cluster from their own machine.

What it is

kubefwd is a command-line utility maintained in the txn2 GitHub organisation and listed in the CNCF Landscape. It discovers the services in a Kubernetes namespace, assigns each service its own unique loopback IP in the 127.x.x.x range, updates /etc/hosts with the service names, and establishes port forwards through the Kubernetes API. The result is that services are reachable by name exactly as they would be from inside the cluster, so a developer can run curl http://api-service:8080, mysql -h database -P 3306, or redis-cli -h cache -p 6379 from their own machine.

The concrete problem it solves is environment-specific connection setup during local development. Instead of starting individual forwards, standing up local service instances, writing Docker Compose files, or editing connection strings for each environment, a developer runs one command and existing connection strings keep working. An application that talks to http://api-gateway:8080 in production, or needs a database at db:5432, an auth service at auth:443, and a cache at redis:6379, uses the same addresses on a laptop. In that sense it replaces the manual practice of running a separate kubectl port-forward per service and the ad hoc configuration that usually grows around it.

Key capabilities

• Bulk forwarding of every service in a namespace with a single command such as kubefwd svc -n my-namespace.
• A unique loopback IP for each service in the 127.x.x.x range, which eliminates port conflicts between services.
• An interactive TUI with real-time service monitoring and traffic metrics, where ? opens help and q quits.
• Automatic reconnection when pods restart or connections drop.
• Live traffic monitoring showing bytes in and out together with HTTP activity.
• Pod log streaming, so container logs can be read from within the TUI.
• A REST API for programmatic control over HTTP endpoints, plus MCP support for integration with AI assistants such as Claude Code and Cursor.

Who uses it and how

• Developers building a local API that must reach a database at db:5432, an auth service at auth:443, and a cache at redis:6379 in a development cluster.
• Teams whose application code uses in-cluster hostnames such as api-gateway:8080 in production and who want the same connection strings to work on a laptop without changes.
• Developers working against a specific Kubernetes namespace, running sudo -E kubefwd svc -n my-namespace --tui to forward the whole namespace at once.
• Engineers who prefer terminal-based observability, using the TUI to watch per-service traffic and stream pod logs while they work.
• Tooling and AI-assisted workflows that drive kubefwd through its REST API or its MCP integration with assistants including Claude Code and Cursor.

Getting started

On macOS the documented installation method is brew install kubefwd; on Linux the README points to downloading the .deb, .rpm, or .tar.gz packages from the project's GitHub releases. A typical run is sudo -E kubefwd svc -n my-namespace --tui, with further detail in the Getting Started and User Guide documentation at kubefwd.com.

How it compares

The facts provided do not name any comparable or competing tool, and no list of paid products that kubefwd replaces is given, so on the evidence available it stands alone in this registry. Its distinguishing characteristics as recorded here are its CNCF Landscape listing and the combination of bulk namespace forwarding, a unique loopback IP per service, and an interactive TUI.

When to use it — and when not to

kubefwd requires elevated privileges, since it binds loopback addresses and rewrites /etc/hosts, and it needs working Kubernetes credentials plus access to the target namespace, which makes it a local development tool rather than something to run in production or shared environments. It is a poor fit for anyone who cannot grant sudo on their workstation or who objects to a tool modifying the system hosts file. The documented installation path also differs by platform, with Homebrew on macOS but manual package downloads on Linux, so Linux users should expect to fetch release artefacts rather than run a single package-manager command.

# Install (macOS)
brew install kubefwd

# Forward all services in a namespace with the interactive TUI
sudo -E kubefwd svc -n my-namespace --tui

curl http://api-service:8080
mysql -h database -P 3306
redis-cli -h cache -p 6379

brew install kubefwd

winget install txn2.kubefwd
# or
scoop install kubefwd

docker run -it --rm --privileged \
  -v "$HOME/.kube:/root/.kube:ro" \
  txn2/kubefwd services -n my-namespace --tui

# Interactive mode (recommended)
sudo -E kubefwd svc -n default --tui

# Multiple namespaces
sudo -E kubefwd svc -n default,staging --tui

# Filter by label
sudo -E kubefwd svc -n default -l app=api --tui

# With REST API enabled
sudo -E kubefwd svc -n default --tui --api