Rejecting the Everything Proxy: Why We Don't Proxy Databases or Kubernetes

When you build an infrastructure access platform, the pressure to expand the scope is immediate. Once you establish a secure control plane, identity integration, and reverse tunnels for SSH, the next requests arrive: “Can you proxy our PostgreSQL databases? What about `kubectl` access? Can you get us onto our Windows boxes over RDP?”

The temptation to say yes to all of it is strong. The “everything proxy” is a popular product category. At Mezite we say yes to some of it — application access for internal web and TCP services is a first-class feature, built on the same reverse tunnels and identity model as SSH. But we draw a hard line at database and Kubernetes API proxying, and we have no plans to add desktop or RDP access either.

Here is why we say no to database and Kubernetes proxying specifically, and why that line — not just “do less” — is the fundamental technical decision.

The Cost of Protocol Parsing

Not every kind of proxying costs the same. The line we draw is about protocol parsing, not about the number of features on a page.

Proxying SSH requires routing encrypted packets over reverse tunnels and managing Certificate Authorities. Forwarding an HTTP or TCP application down that same tunnel and stamping the request with a signed identity header costs us almost nothing extra — it reuses the tunnel and the CA we already operate. But proxying a database protocol like PostgreSQL requires understanding the wire protocol: terminating TLS, parsing the query stream, and re-establishing a connection on the other side. Proxying Kubernetes requires intercepting and authenticating complex, multiplexed HTTPS API calls and translating them against the cluster’s RBAC model.

When you add complex state machines and protocol parsers to your control plane, you meaningfully increase the attack surface. A bug in a database protocol parser or an HTTP/2 stream demultiplexer can expose the entire access platform to exploitation. By keeping wire-protocol parsing out of scope, we keep the attack surface of the `mezhub` binary small and easily auditable.

The Single Binary Philosophy

We design Mezite to run anywhere. We distribute it as a single, statically-linked Go binary. For state storage, it requires only SQLite or PostgreSQL.

When a platform tries to be an “everything proxy,” the operational requirements balloon. You suddenly need different agents for different wire protocols, complex sidecar deployments for Kubernetes, and translation layers for whatever database engines your teams have standardized on. The deployment goes from a simple binary execution to a sprawling collection of protocol-specific components.

We refuse to compromise on operational simplicity. Your infrastructure access tool should be the most reliable, easiest-to-deploy software in your stack. Staying out of the database and Kubernetes protocol-parsing business is what lets us keep the single-binary, zero-dependency model — whether you’re using it for SSH or for the applications layered on top of it.

Doing One Thing Extremely Well

By ignoring the distraction of bespoke wire protocols, we dedicate our engineering effort to solving the deepest, most complex challenges of SSH access.

Because we do not have to build a database proxy or a Kubernetes API gateway, we engineer a better SSH architecture. We build zero-inbound-port reverse tunnels so your nodes stay hidden. We implement single-port ALPN multiplexing so you only need to open port 443. We push SSH session recording to the edge, capturing clean PTY output directly on the target node instead of bottlenecking the central proxy.

SSH access is the foundation of infrastructure control. It is the fallback when everything else breaks, and the primary tool for systems engineering. It deserves a dedicated, purpose-built tool.

Conclusion

Engineering is about boundaries. The boundary we draw isn’t “SSH and nothing else” — it’s “no bespoke wire-protocol parsing.” That’s why application access, which reuses the tunnel and identity primitives we already built for SSH, is in scope, while database and Kubernetes proxying, which would require an entirely new class of protocol parsers in the critical path, are not. The “everything proxy” might look impressive on a feature matrix, but when you manage access to your most critical infrastructure, a minimal attack surface and operational simplicity matter far more than checking every box.

---