Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
TL;DR: I built Inkube, a tool that lets you run local services with the same environment, network access, and runtime conditions as a Kubernetes pod — without actually deploying. Built to ease local development in complex k8s setups.
The Problem: Dev Inside Kubernetes is Painful
If you've ever worked with a large distributed system deployed in Kubernetes, you know how hard it is to:
Mirror the cluster environment locally.
Connect to in-cluster services (via DNS or service discovery).
Access environment variables, secrets, and configmaps.
Debug or test things without full deployment cycles.
This setup cost me hours of context switching. I wanted a way to spin up my app locally but have it behave like it's in the cluster.
The Solution: Inkube
I created Inkube to address this exact need.
✨ What it does:
🧠 Mirrors the runtime environment of any pod (
env vars,env mounts)🌐 Provides network tunneling, so your local app can access in-cluster services (and vice versa)
🔐 Pulls secrets/config directly from the pod spec
📦 Includes a package manager for syncing dependencies
🧪 Great for debugging, testing, or iterative development — without a full CI/CD cycle
Powered By Devbox + KubeVPN
Inkube uses:
🧰 Devbox to install & lock matching system packages for application.
🌐 KubeVPN under the hood to establish bidirectional tunnels and handle DNS/networking.
But Inkube wraps both in a dev-friendly, zero-config CLI so you don't have to fight with flags or YAML.
How It Works
Choose a pod: You tell Inkube which pod in the cluster you want to mirror.
Inkube pulls metadata: It extracts env vars, mounts, and config.
Tunnels traffic: It creates a bidirectional tunnel between your machine and the cluster.
Local launch: Run your app locally — but it behaves as if it's inside the cluster.
Think: Telepresence, but simpler, more dev-focused, and built for quick iteration cycles.
Why This Matters
Modern teams often have robust Kubernetes setups — but devs don’t always want to (or can’t) replicate full environments locally. Tools like Tilt, Skaffold, and Telepresence exist, but each has a learning curve or infra requirements.
Inkube is intentionally minimal and developer-first. Ideal for:
Working on one service in a large microservice setup
Troubleshooting integration issues
Exploring services in unfamiliar clusters
Avoiding long deploy cycles for every small change
Example Usage
inkube init # you will get prompt to pick namespace, deployment & container
devbox add <pkg> # install package
inkube dev # you will access the shell with all env vars mounted and network access
inkube intercept # all traffic coming on deployment will start hitting your local machine.
# it will also stop all running container of that deployment.
inkube leave # stop intercepting traffic.
exit # exit from ther inkube shell
Your local process now:
Has the same env vars as selected deployment’s container.
Talks to other services via in-cluster DNS
Can receive traffic from the cluster (via tunnel)
Logs and behaves like it's "inside"
Initialize
Access Development Shell
Intercepting Traffic
Accessing Container Environments
Package Manager
Open Source & Contributions Welcome
Inkube is open source (MIT). You can check it out here:
🔗 https://github.com/abdheshnayak/inkube
If this scratches an itch you’ve had, or if you have feedback — I’d love to hear it.
Thanks for reading!
If you found Inkube helpful, consider sharing it with a friend or teammate. Your feedback means a lot!