kubefwd

MCP.Pizza Chef: txn2

Once it's running, every service inside a Kubernetes cluster becomes reachable from your own computer using its normal name, so code that expects to find a database, cache, or another service on the cluster keeps working without any changes. It runs from the command line and can also connect into Cursor. Using it requires administrator-level access on your computer and an existing connection to a Kubernetes cluster — there's no extra account or key to set up.

Coding
Data

Use This MCP server To

Test my app against real cluster services without extra setup Reach a cluster database or cache directly from my own computer Work on one service locally while everything else stays in the cluster Watch live traffic and logs from cluster services in one place Skip juggling separate port numbers for every service I need Keep my code's existing connection settings working during local testing

README

kubefwd (Kube Forward)

kubefwd - kubernetes bulk port forwarding

CNCF Landscape GitHub license codecov Go Report Card GitHub release GitHub Downloads OpenSSF Scorecard OpenSSF Best Practices SLSA 3

Documentation | Getting Started | User Guide | API Reference | MCP (AI Integration)

Develop Locally, Connect to Kubernetes

kubefwd enables developers to work on their local machine while seamlessly accessing services running in a Kubernetes cluster. If you're building a new API that needs to connect to a database at db:5432, an auth service at auth:443, and a cache at redis:6379, all running in your development cluster, kubefwd makes them available locally by their service names, exactly as they would appear in-cluster. No environment-specific configuration, no local service setup, no Docker Compose files. Just run kubefwd and your application's existing connection strings work.

This is the essential use case: reduce or eliminate environment-specific connection setup and configurations during local development. Your code uses http://api-gateway:8080 in production? It works the same way on your laptop with kubefwd.

Bulk Kubernetes port forwarding with an interactive TUI, unique IPs per service, and automatic reconnection.

kubefwd FAQ

Can I use this to test my app against real databases and services running in a cluster?
Yes — once you turn it on for a project area in your cluster, your app can talk to those services by their usual names, just like it would if it were also running inside the cluster.
Do I need an account or a key to use this?
No account or key is required. It uses the cluster access you already have set up through kubectl, the standard command-line tool for talking to Kubernetes.
Which apps does this work with?
It's a command-line tool you run from your terminal, and it also connects into Cursor. It isn't something you install as an app with an icon.
How hard is it to set up?
It takes real technical setup. You install it with a package manager or Docker, and you need administrator access on your computer plus an existing connection to a Kubernetes cluster.
Do I need to already know Kubernetes well to use this?
You need a working connection to a Kubernetes cluster and comfort running commands in a terminal. It's built for people who already work with Kubernetes regularly, not as a first introduction to it.
Can I use this to work on one part of my app locally while the rest keeps running in the cluster?
Yes — you can develop and test a single piece on your own computer while it still reaches every other service in the cluster normally, with no changes to your code's connection settings.
Will it interfere with my everyday internet connection?
No. It gives each cluster service its own private address on your computer, so it runs alongside your normal internet use without conflicts.
Can I see what's happening while it's running?
Yes — it includes a live view in the terminal that shows connection activity and traffic for each service, plus the ability to view service logs.