72 2026-01-04 · 2 MIN · SHORT-FORM

kubefwd: Forward Kubernetes Services to Localhost by Name

One command, no configuration, automatic reconnection

Diagram · 72

flowchart TB
  APP(["Your App"])
  APP -->|"postgres:5432"| HOSTS
  HOSTS["/etc/hosts entry"]
  HOSTS -->|"127.1.27.1:5432"| KFWD
  KFWD{{"kubefwd listener"}}
  KFWD -->|"port-forward channel"| KAPI
  KAPI["kubectl port-forward"]
  KAPI -->|"TCP to pod IP"| POD
  POD[("postgres pod in cluster")]

kubectl port-forward works fine for one service. Two services? Three? A microservices app with a dozen dependencies? You end up with a terminal full of port-forward commands, each needing different local ports to avoid conflicts, and connection strings that differ between local and production.

§Forward by name

kubefwd bulk-forwards Kubernetes services so they’re accessible by their real hostnames:

brew install txn2/tap/kubefwd
sudo -E kubefwd svc -n mynamespace

Your app connects to postgres:5432 and redis:6379 locally, using the same hostnames it would use inside the cluster.

§How It Works

Your App → postgres:5432
         → /etc/hosts: postgres = 127.1.27.1
         → kubefwd listens on 127.1.27.1:5432
         → forwards to pod in Kubernetes cluster

kubefwd creates unique loopback IPs for each service (127.1.27.1, 127.1.27.2, …) so multiple services can use the same port. It adds entries to /etc/hosts and cleans them up on exit.

§Why Sudo?

kubefwd modifies /etc/hosts and binds to loopback addresses. Both require root on Unix systems. Unlike kubectl port-forward which uses unprivileged high ports, kubefwd preserves the real service ports so your configuration matches production.

All modifications are temporary. kubefwd removes /etc/hosts entries and releases network bindings when it exits.

§New in 2026

Auto-reconnect that survives pod restarts, deployments, VPN drops, and laptop sleep/wake
Interactive TUI for browsing namespaces, forwarding services, and viewing pod logs (--tui)
REST API with 40+ endpoints for programmatic control
MCP server so an AI assistant can manage forwarding

Full feature guide

§vs. Telepresence

Different tools for different problems.

kubefwd is the local-to-cluster direction: your app connects to cluster services by name, traffic flows one way. Telepresence is the other direction: cluster traffic routed to your machine, interception, preview URLs, debugging against live requests.

kubefwd is one binary, one command, no cluster components. Telepresence does more, and it requires more. Pick the one that matches the traffic direction you need.

§Install

macOS: brew install txn2/tap/kubefwd

Linux: Download from releases

Windows: scoop install kubefwd

§Links

Craig Johnston · 2026-01-04 ← back to all notes