Cloudflare Tunnel

A Cloudflare Tunnel puts an application on the internet at a hostname of yours without opening a port. Each node makes outbound connections to Cloudflare, and Cloudflare sends requests for that hostname back down them.

ProxDock runs one tunnel for the whole cluster. You turn it on once, then publish applications one at a time from their own page.

Status: new in 0.70.0. There are no screenshots yet.

What you need#

• A domain on Cloudflare. Its DNS must be hosted there; registering it elsewhere is fine.
• A Cloudflare API token for ProxDock, created under My Profile → API Tokens, with exactly these permissions:

The zone permissions are needed on every zone you want to publish hostnames in.

This is a separate token from the one used for certificates. Certificates need permission to write TXT records, and the tunnel needs to manage tunnels and CNAMEs. Keeping them apart means neither credential holds more than its own job needs.

Turning it on#

Settings → Networking → Cloudflare Tunnel takes the API token and your account ID. The account ID is on the Cloudflare dashboard's account overview.

Saving with Enabled on does three things:

1. Creates a tunnel named proxdock-<cluster>, or adopts it if one with that name already exists. A cluster you rebuild under the same name picks its tunnel back up instead of creating a second.
2. Fetches the tunnel's connector token. It is kept in the cluster store and never shown again, like every other credential.
3. Starts a connector on every node within a minute.

The Status panel asks Cloudflare which connectors are attached, so it shows Cloudflare's view rather than ProxDock's. One connector per node is the healthy state.

One connector per node#

Cloudflare treats the connectors as replicas of one tunnel. If a node goes down, traffic carries on through the others, with nothing to fail over.

A connector is cloudflared running in a container on a plain Docker bridge. It is not an application, so it has no zone address, is never backed up and never migrates. It reaches applications the way any other client on that node would, through the node's own routing. Every node must be able to reach your zones' addresses. That is true of most networks, including ones where the nodes sit on a separate management VLAN and reach the zones through a router.

Publishing an application#

On the application's Overview tab, Public hostnames → Publish asks for three things:

ProxDock then routes books.example.com to http://10.42.0.15:6875 (the application's own address and port) and creates a proxied CNAME pointing the hostname at the tunnel. It is usually reachable within a minute.

For an https origin, accept the application's certificate without verifying it covers the self-signed and cluster-CA certificates most applications start with. Visitors still get Cloudflare's publicly trusted certificate either way; this setting only affects the hop between the connector and the application.

A few rules hold:

• A hostname that already has a DNS record is refused. That record is serving something, and ProxDock will not take it over. Remove it in Cloudflare first.
• A hostname belongs to one application. One application may have several.
• The application needs a zone address. The tunnel reaches applications there, so an internal-only stack cannot be published.
• Publishing takes manage access on the application, the same as sharing it with a team. It puts the application in front of everyone.

Anyone on the internet can reach a published application. Its own login is what protects it.

Migrations, unpublishing and deletion#

A route stores the scheme and port, not the address. The address is read from the application when the route is written to Cloudflare. An application keeps its address when it migrates, so a migration changes nothing about its routes.

Unpublish removes the route and its DNS record. Deleting an application unpublishes all of its hostnames first.

ProxDock owns the tunnel's routes#

ProxDock writes the tunnel's whole route list, and the cluster's leader writes it again every ten minutes. That repairs anything a failed or overlapping change left behind, and it also means changes made to this tunnel's public hostnames in the Cloudflare dashboard do not last. Make them in ProxDock. A hostname ProxDock does not know about answers 404.

Turning the tunnel off stops every connector, so published hostnames stop answering. Routes, DNS records and the tunnel itself stay, and turning it back on resumes where it left off.

Running your own tunnel instead#

The bundled Cloudflare Tunnel application is still in the library. It runs cloudflared as an ordinary application with a token you create yourself, and leaves the routes to you, in the Cloudflare dashboard. Use it if you would rather not hand ProxDock an API token, or if the tunnel serves things outside the cluster.