A Cloudflare Tunnel alternative: publish, or keep it private

What Cloudflare Tunnel solves well

The principle behind Cloudflare Tunnel is elegant: a small daemon, cloudflared, runs next to your service and establishes an outbound connection to Cloudflare's network. Visitor traffic arrives on that network, then comes back down through the tunnel to your machine. The result: no inbound port to open, no forwarding rule to configure on the router, and the service works even behind a home NAT or a carrier-grade NAT, where hosting a conventional server is impossible.

• Exposure without an open port: the machine hosting the service does not listen from the internet; it connects outward to Cloudflare's network.
• The protection of a global network: public traffic first lands on Cloudflare's infrastructure, which absorbs denial-of-service attacks before they reach your machine.
• Managed names and certificates: visitors reach a domain name over HTTPS without you installing any certificate on the origin machine.
• Hidden origin address: visitors only ever see Cloudflare's network, never the IP address of your own connection.

The underlying question: who terminates TLS

To understand what you are really choosing, you have to distinguish two families of tools that are often conflated. An exposure tunnel makes a private service reachable from the public internet: anyone can connect to it, and an intermediate infrastructure receives that public traffic and relays it to the origin. A private network, by contrast, connects your machines to each other: nobody else can connect to it, and traffic is encrypted from one end to the other between the two machines talking.

The difference crystallizes around one precise technical point: who terminates TLS. In Cloudflare Tunnel's documented public architecture, visitors' HTTP traffic transits Cloudflare's infrastructure, which terminates the TLS connection on the public side before forwarding requests down the tunnel. It is a coherent architectural choice — it is what makes caching, attack inspection and the global network's protection possible — and it is openly documented. You simply have to draw the conclusion: an exposure tunnel is not an end-to-end private network, and it does not claim to be one.

When nothing should be public: the private mesh

If the service is meant only for you, your team or your machines, VIGIL-MESH keeps it entirely off the internet. Each machine joins a private mesh network using outbound connections only — a single flow on 443 UDP, the same port as the modern web — with no inbound port and no router configuration, including behind a 4G/5G carrier-grade NAT. The connection goes through a relay immediately, then migrates without interruption to the direct peer-to-peer path as soon as NAT traversal succeeds.

This access control is not a mere configuration option: every policy change produces a new generation signed by the controller, which each client verifies cryptographically — including offline — before applying it. Belonging to the network grants no rights by itself; without a rule allowing it, a flow is denied. It is a Zero Trust model, not a flat network.

And because no public door exists, the service's attack surface toward the internet drops to zero: nothing to scan, nothing to brute-force, nothing to shield from a denial of service. The best defense for a service that was never meant to be public is not being reachable at all.

When you really must expose: publication

Sometimes a service genuinely has to be reachable from the public internet: a web application for users who are not mesh members, an API consumed by partners, a TCP entry point for a business protocol. VIGIL-MESH covers this need with the platform's publications. The principle stays the same as for the mesh: the machine hosting the service opens no inbound port, it joins the mesh outward; the platform is what presents a public surface and relays inbound traffic to the service through the encrypted mesh.

A publication is an explicit, surgical act: each publication opens a door to exactly one internal service. The rest of the network — addresses, machine names, unpublished services — stays invisible to the visitor. Over HTTP, the platform acts as a reverse-proxy: it terminates TLS on the public side with a certificate obtained and renewed automatically, then carries the request to the service. Over TCP, it relays the raw stream without interpreting it — and therefore without encrypting it for you: the published protocol (SSH does so natively) must provide its own encryption.

Let us be honest about the comparison: as soon as you publish over HTTP, someone terminates TLS on the public side — that is true for a VIGIL-MESH publication just as it is for Cloudflare Tunnel. The difference is no longer about end-to-end, but about scope and scale. And on scale, Cloudflare has a genuine advantage: its global network doubles as a CDN and absorbs massive denial-of-service attacks close to their source. For a public site with heavy worldwide traffic or particular exposure to attacks, that is a strength VIGIL-MESH publication does not claim to match.

Sovereignty: whose servers carry your bytes

One question remains that exposure tunnels never raise: who owns the infrastructure your traffic crosses? With a managed tunnel, the answer is structural — traffic goes through the tunnel operator's network. With VIGIL-MESH, your machines' traffic takes the direct peer-to-peer path whenever it exists, crossing no infrastructure at all. And for the relayed share, you can take back control.

• Self-hosted private vigie: you deploy your own relay on your own server; it registers automatically with the controller and serves only your workspace. Your relayed bytes transit only through your machines.
• Blind even at home: the vigie — yours as much as the service's — does not hold the session keys. Self-hosting serves path sovereignty, proximity and compliance, not content confidentiality, which end-to-end encryption already guarantees.
• Proximity and compliance: a relay in your datacenter or your region shortens the detour taken by relayed traffic and keeps it within your contractual and geographic perimeter.

Which tool for which need

The choice does not boil down to "Cloudflare Tunnel or something else": it depends on who must reach the service. This table maps each need to the tool that fits it — including when that tool is not ours.

The last two rows are the heart of the matter: most services in a homelab or a small infrastructure do not need to be public. Putting them on the mesh, and publishing only the exception, shrinks the attack surface far more reliably than any protection placed in front of an exposure.

Getting started: the two scenarios

First scenario, the most common one: reaching your services without exposing anything. Everything happens from the console, without touching the router or the firewall.

1. 1
   Create an account and a workspaceThe workspace gathers your networks, your machines and your access policies. It is free for personal use.
2. 2
   Install the client on the machines involvedThe machine hosting the service (NAS, server, home-automation box) and the ones that need to reach it — Windows, Linux, Android, Jetson, or even the browser through the WASM node.
3. 3
   Enroll each machineNetworks page → Machines → "Add a machine": a single-use key enrolls the machine into the network.
4. 4
   Verify connectivityEach machine receives a stable address and a MagicDNS name; a ping or opening the service confirms the mesh is in place.
5. 5
   Reach the service by its nameFrom any machine on the network, reach the service through the machine's address or name, as if local. Nothing has been exposed to the internet.

Second scenario: the service must be reachable by visitors outside the mesh. That is where an HTTP publication of the platform comes in.

1. 1
   Designate the internal service to publishThe mesh machine and the port on which the web application is listening. The service keeps running exactly as before, unmodified.
2. 2
   Choose the public nameThe domain or subdomain through which visitors will reach the service; its management is described in the domains documentation.
3. 3
   Let the platform obtain the certificateThe public name's TLS certificate is requested and renewed automatically — no file to install, no expiry date to watch.
4. 4
   The reverse-proxy relays to the serviceInbound traffic is terminated on the public side then carried to the internal service through the encrypted mesh. The rest of the network stays invisible.

Frequently asked questions