Proxera is a self-hosted reverse tunnel platform designed to expose private services without opening inbound ports, while keeping infrastructure ownership and routing control in the operator’s hands. It positions itself as an alternative to Cloudflare Tunnel by using the same outbound-connection model, but without depending on Cloudflare’s managed edge and account model.
For teams running home labs, private Kubernetes clusters, internal APIs, or edge workloads, that is a compelling combination: the operational simplicity people like about cloudflared-style tunnels, paired with a fully self-hosted stack and a product experience built around visibility and control.
Why Proxera stands out
The strongest part of Proxera is its focus on practical operations. The project highlights outbound-only agents, multi-domain routing, live topology and logs, token-based agent registration, Kubernetes and Docker readiness, and horizontal scaling support. That means it is not just a tunnel endpoint; it is built as an admin-friendly system for running tunnels as real infrastructure.
Several features make that especially attractive for operators who have outgrown ad-hoc reverse proxies or one-off tunnel daemons:
- Zero inbound ports, because agents connect outbound only and the private-side firewall can stay closed.
- Multi-domain and path-based routing over a single persistent agent connection.
- Live topology and route-level logs for visibility into agents and traffic flows.
- One-time registration tokens for controlled, auditable onboarding of new agents.
- Kubernetes-focused deployment with Helm charts for both server and agent components.
- Built-in Ingress resource management from the admin UI for Kubernetes environments.
That combination is what makes Proxera feel awesome in practice: it gives the convenience of tunnel-based publishing, but treats observability, onboarding, and cluster integration as first-class features instead of afterthoughts.
Proxera vs. cloudflared
Cloudflare Tunnel works by running cloudflared inside infrastructure, where it creates outbound-only connections to Cloudflare’s network so services can be published without exposing a public origin IP. Proxera uses a very similar traffic model at the connection layer, but the control plane and routing stack are self-hosted, which changes the trade-off from managed convenience toward ownership, customization, and infrastructure independence.
| Aspect | Proxera | Cloudflare Tunnel |
|---|---|---|
| Connectivity model | Outbound-only agent connection from the private network to the server. | Outbound-only cloudflared connection from origin to Cloudflare. |
| Hosting model | Fully self-hosted and open source. | Managed through Cloudflare’s network and account ecosystem. |
| Firewall posture | No inbound pinholes required for private-side services. | No inbound ports required on the origin side. |
| Operational visibility | Live topology view and route-level request logs are part of the product story. | Cloudflare emphasizes secure connectivity and edge services; observability depends on its platform features. |
| Kubernetes integration | Helm charts for server and agent, plus Ingress resource management in the admin UI. | Tunnel integrates with Cloudflare routing and edge services rather than a self-hosted ingress control plane. |
For readers already familiar with cloudflared, the short version is simple: Proxera offers the same core appeal of outbound-only tunneling, but gives operators their own platform to run, inspect, and extend.
A quick architecture dive
At a high level, Proxera follows a clean four-part path: a public request reaches the Proxera server, the server forwards traffic over a persistent outbound tunnel to a Proxera agent, and the agent delivers that traffic to a private service inside your private network / LAN. The key architectural idea is that the agent initiates the connection outward, so there is no need to expose inbound ports on the private network.
That model matters because it reduces attack surface and simplifies deployment in places where firewall changes, port forwarding, or VPN rollout would otherwise slow everything down. It also maps well to modern platform setups, because Proxera supports Helm-based deployment, multi-pod scaling with Redis Pub/Sub, and private-network use cases ranging from home labs to production clusters.
Where Proxera fits best
Proxera supports and a enables a wide range of use cases such as home lab access, secure internal APIs, preview environments, edge and IoT services, dev team tools, and zero-inbound enterprise setups. Those examples all share the same need: safely publish selected private workloads without turning the internal network into a public edge.
That makes Proxera especially interesting for operators who want a sharper separation between public ingress and private runtime environments, while still keeping rollout lightweight and developer-friendly. In other words, it is not only a tunnel; it is an opinionated platform for running tunnels well.
Getting started
The fastest way to explore Proxera is through the official website and source repository:
- Website: proxera.wenisch.tech
- GitHub: github.com/wenisch-tech/proxera
The project site includes a quickstart that shows Helm-based installation for the Proxera server and agent, including WebSocket-based agent connectivity and token-based registration. That makes it straightforward to test the full model in a lab first and then carry the same pattern into larger Kubernetes environments.