Moving From Local Dev to Production: Piko as an Open-Source Ngrok Alternative for Kubernetes Clusters

Every developer remembers the first time they used ngrok: one command, and a local server on localhost is reachable from the public internet. For testing webhooks, sharing a work-in-progress build, or hacking together a quick integration, it works well.

But that same reverse-tunneling pattern behaves differently once you need it for production services running inside a Kubernetes cluster. At that point the requirements change — you need fault tolerance, horizontal scaling, and control over your data plane, ideally without a SaaS licensing bill that scales with usage.

This is the gap Piko is built to fill: an open-source, Go-based reverse proxy and tunneling system, MIT-licensed, created by Andy Dunstall and hosted at github.com/andydunstall/piko. Its own documentation describes it plainly as “an open-source alternative to Ngrok, designed to serve production traffic and be simple to host (particularly on Kubernetes).”

How Reverse Tunneling Works, and Where It Struggles at Scale

Traditional ingress requires opening an inbound port — you poke a hole in your perimeter so the internet can reach your service.

Reverse tunneling inverts this: your internal service makes an outbound connection to an external edge server, which then routes public traffic back down that already-established tunnel. Outbound connections are almost universally permitted by corporate firewalls, so there’s no NAT configuration, no port forwarding, and no security-review cycle to get through.

The friction shows up when you take a tool built around a single developer’s laptop and try to run it as production infrastructure in a cluster:

• Single point of failure — a standalone tunnel client that crashes drops traffic until it restarts.
• Horizontal scaling limits — load-balancing a large number of concurrently connected tunnel clients isn’t something every local-dev tool is designed for.
• Data residency — unless you’re on a self-hosted or enterprise plan, traffic passes through a third-party SaaS edge, which is a nonstarter for some compliance requirements.
• Cost at scale — bandwidth- or endpoint-based SaaS pricing scales linearly with your footprint.

What Piko Actually Does Differently

Piko isn’t meant to run as a single binary on a laptop — it’s designed to run as a cluster of nodes, and its own docs are explicit that this is the point: it’s “built to serve production traffic by running as a cluster of nodes for fault tolerance, horizontal scaling and zero-downtime deployments.”

The mechanics: your upstream service (or the Piko agent running next to it) opens an outbound-only connection to a Piko server node and registers the endpoint it’s listening on. Piko never opens a connection to your service — it only ever forwards traffic down the connection your service opened to it. That means the service can run anywhere, with no exposed port and no public route, as long as it can reach the Piko server.

High availability via gossip

Because pods are ephemeral, Piko is designed to run as multiple server nodes that discover each other and share cluster state. If an upstream is connected to node A but a request lands on node B, node B looks up which node holds the connection and forwards the request internally.

To keep every node’s view of “which endpoint is connected where” in sync, Piko uses a gossip-based anti-entropy mechanism. When upstreams connect or disconnect, that state change propagates around the cluster — according to Piko’s own documentation, typically in under a second, not instantaneously. If a node fails or is deprovisioned, the affected upstream reconnects to a surviving node and the new routing state is propagated the same way. This is what makes it reasonable to run Piko as a Kubernetes StatefulSet behind a standard HTTP(S) load balancer.

One real operational constraint worth flagging: Piko’s own docs recommend deploying a single cluster within a single region, distributed across availability zones — it isn’t designed out of the box as a multi-region active-active system. That’s a meaningful caveat if “high availability” is doing a lot of work in your evaluation.

Four ports, not one

A Piko server node exposes four distinct ports, each with a specific job (shown here with the default values from Piko’s Kubernetes deployment example):

Port	Default	Purpose
Proxy	8000	Receives HTTP(S) traffic from downstream clients and routes it to the correct upstream. Depending on your deployment, this may be public-facing or only reachable from clients on the same network — for example, in a BYOC setup where the client is your own control plane.
Upstream	8001	Where upstream services (agents or the Go SDK) connect to register an endpoint and hold their outbound tunnel open.
Admin	8002	Serves the status API, cluster/node health checks, and a Prometheus /metrics endpoint. Piko’s docs are explicit that this port should not be exposed to the internet, and if you must expose it, you should enable TLS and authentication.
Gossip	8003	Node-to-node only. Carries the gossip protocol traffic used for service discovery and routing-state propagation.

Because the admin port exports Prometheus metrics natively, wiring up Grafana dashboards for tunnel health and throughput is straightforward without custom instrumentation.

Routing without wildcard DNS

When a request hits the proxy port, Piko identifies the target endpoint from either the Host header (using the first subdomain segment — e.g., foo.piko.example.com routes to the foo endpoint) or a custom x-piko-endpoint header, which lets you skip setting up wildcard DNS entirely.

TCP traffic can’t carry a header, so for TCP tunnels you connect through piko forward (which maps a local TCP port to a target endpoint) or the Go SDK, rather than connecting straight to the server.

Authentication

Piko authenticates connecting clients with a JWT provided by your own application. It supports HMAC, RSA, and ECDSA signing (specifically HS256/384/512, RS256/384/512, and ES256/384/512), and each port — proxy, upstream, and admin — can be configured with independent auth settings. A JWT can optionally carry a piko claim scoping the token to specific endpoints; if that claim is absent, the token can access any endpoint. Piko also supports mutual TLS, added in release v0.6.4, and JWKS-based key verification, added in v0.8.0, alongside multi-tenant upstream authentication in that same release.

Bring-Your-Own-Cloud (BYOC)

This is the use case Piko’s own maintainers point to explicitly, alongside “expose services in a customer network” and “connect to user devices.” It addresses a specific, common enterprise problem: a vendor needs to manage and monitor software that runs deep inside a customer’s own VPC, and the customer’s security team will not open inbound firewall ports for a third party’s control plane.

With Piko, the vendor runs a Piko server cluster centrally, and a lightweight Piko agent runs inside the customer’s environment alongside the workload. The agent opens an outbound-only connection back to the vendor’s cluster — which, to the customer’s firewall, looks like ordinary outbound web traffic. Once that tunnel is up, the vendor’s control plane can route requests, trigger deployments, or scrape metrics through it, without VPN tunnels, VPC peering, or custom NAT gateways per customer. (The “50 customers, 50 security reviews” framing here is illustrative of the pattern Piko documents, not a direct quote from its docs.)

Deploying Piko

Piko ships a Helm chart at operations/helm in the repository, which creates a headless Service and a StatefulSet. The one hard requirement on your load balancer is WebSocket-upgrade support, since that’s how upstream agents hold their persistent outbound connections open.

Registering an upstream is a single command. The agent binds to your service’s local port and opens the tunnel:

# Connects a local service on port 4000 to the Piko cluster
# under the endpoint name "my-endpoint"
piko agent http my-endpoint 4000

The same piko binary handles both roles — piko server to run a node, piko agent http|tcp to register an upstream, and piko forward for TCP clients. Docker images are published to ghcr.io/andydunstall/piko.

Current State of the Project

As of this writing, Piko is at v0.10.0 (released May 8, 2026), and development has been active and incremental over the past two years — mutual TLS support (v0.6.4, December 2024), connection rebalancing across the cluster (v0.7.0, February 2025), JWKS and multi-tenant upstream auth (v0.8.0, August 2025), graceful client shutdown (v0.9.0, January 2026), and configurable stream window sizing (v0.10.0, May 2026).

Two things worth weighing before betting production traffic on it:

• It’s still pre-1.0. Versioning at 0.x doesn’t mean it’s unstable, but it does mean the project hasn’t declared a stable, backward-compatible API surface yet.
• It’s a small but real community. At the time of writing the repository has roughly 2,200 GitHub stars and 87 forks, and it’s listed in the community-maintained awesome-tunneling directory — which, as of a February 2026 policy update, now requires at least 100 GitHub stars for any new tool to be added. Piko clears that bar, but it’s still a single-maintainer-led project rather than a large team.

ngrok vs. Piko: Where Each One Fits

ngrok is not obsolete, and nothing here suggests it should be for its actual target use case. For a developer testing a Stripe webhook locally, sharing a preview build with a client, or wanting someone else’s edge to absorb DDoS traffic, ngrok’s managed experience is hard to beat.

The dividing line is production Kubernetes infrastructure — specifically BYOC ingress, environments with data-residency constraints, or high-traffic internal services where a third party’s edge isn’t an option. For that case, Piko offers the operational shape of a reverse tunnel with a cluster-native architecture you host and control yourself, at the cost of running and operating that cluster — and of adopting a pre-1.0 project rather than a mature managed product.

---

Fact-Check & Changelog

Verified against Piko’s official GitHub repository, wiki, and release notes (all links below).

• Corrected propagation timing. The draft claimed gossip state propagates “in milliseconds.” Piko’s own wiki states routing updates are “usually” propagated “in less than a second” — corrected accordingly. (How Piko Works)
• Softened the failover claim. The draft said a failed node causes “instant” reconnection. Piko’s docs describe automatic reconnection to a surviving node without giving a specific latency figure — removed the unsupported “instant” framing.
• Added exact port numbers. The draft described four ports conceptually with no values. Confirmed and added the actual defaults (8000/8001/8002/8003) from Piko’s Kubernetes deployment example. (Server Kubernetes)
• Added the admin-port security warning. Piko’s docs explicitly state the admin port “should not be exposed to the Internet,” and if it must be, TLS and auth should be enabled — this specific guidance wasn’t in the original draft. (Server)
• Verified and specified JWT support. Confirmed Piko supports HMAC, RSA, and ECDSA JWT signing algorithms with per-port configuration and optional endpoint-scoping claims, rather than a generic “JWT authentication” mention. (Authentication)
• Verified and dated mTLS support. Confirmed mutual TLS support, added in release v0.6.4 (December 2024). (Releases)
• Verified the Helm chart claim. Confirmed the chart exists at operations/helm in the repo and creates a headless Service + StatefulSet. (Server Kubernetes)
• Verified BYOC as an official use case, not just marketing framing — Piko’s own wiki lists “a bring your own cloud (BYOC) service” as a stated use case. (What Is Piko?)
• Added project maturity context not present in the original draft: current release (v0.10.0, May 2026), pre-1.0 versioning, and approximate community size (~2,200 stars, 87 forks), plus third-party validation via inclusion in the awesome-tunneling list under its 100-star minimum policy. (Releases, awesome-tunneling)
• Added the single-region caveat. Piko’s docs recommend a cluster be deployed within a single region across availability zones — a real limit on the HA story that the original draft omitted. (Server)
• Clarified TCP tunnel routing. Made explicit that TCP tunnels require piko forward or the Go SDK, since raw TCP has no header to identify the target endpoint. (What Is Piko?)
• Stripped SEO/AI-draft artifacts: removed unverifiable superlatives (“the gold standard,” “brilliant,” “the industry is pivoting”) and any leftover metadata framing not relevant to a technical readership.