Introduction

Cloudflare Tunnel is one of the simplest ways to expose self-hosted applications without opening inbound ports on a VPS. A common question arises when infrastructure grows beyond a single server:

What happens if I run the same Cloudflare Tunnel on multiple VPSes?

Can it be used for high availability? Does it automatically become a load balancer? Can different servers expose different services through the same tunnel? What breaks when applications become stateful?

This article explores these questions in depth and covers several real-world deployment scenarios.

Understanding Cloudflare Tunnel Connectors

A Cloudflare Tunnel consists of:

• A Tunnel ID (UUID)

• Tunnel credentials

• One or more cloudflared connector instances

A single tunnel may have multiple active connectors.

For example:

 Cloudflare Edge
 |
 Tunnel: prod-tunnel
 |
 +------------+------------+
 | |
 Connector A Connector B
 VPS1 VPS2

Both VPSes establish outbound connections to Cloudflare. No inbound ports are required.

Common Misconception: "Multiple Connectors = Failover Only"

Many administrators assume:

VPS1 active
VPS2 standby

and that Cloudflare only switches to VPS2 when VPS1 dies. That is not entirely accurate. Cloudflare can utilize multiple healthy connectors attached to the same tunnel simultaneously.

Conceptually:

Request 1 -> VPS1
Request 2 -> VPS2
Request 3 -> VPS1
Request 4 -> VPS2

However, this should not be confused with a dedicated load balancer.

Cloudflare Tunnel does not provide:

• Weighted traffic distribution

• Service-level health checks

• Session affinity

• Canary deployments

• Geographic routing

• Blue-green deployments

Those features belong to Cloudflare Load Balancing.

Scenario 1: Identical Services on Both VPSes

Consider:

VPS1
 ├─ Express API
 ├─ Directus
 └─ Umami

VPS2
 ├─ Express API
 ├─ Directus
 └─ Umami

Both servers:

• Run the same tunnel

• Use the same tunnel credentials

• Use the same ingress configuration

This setup works well.

 Client
 |
 Cloudflare
 |
 Tunnel
 |
 +------+------+
 | |
 VPS1 VPS2

Traffic can reach either VPS. This is the closest thing to horizontal scaling that Tunnel provides by itself.

The Hidden Requirement: Shared State

Most scaling failures occur because applications are not truly stateless.

Express API

Usually safe if:

• Stateless

• JWT authentication

• External session storage

Example:

VPS1 -> Express
VPS2 -> Express

No issues.

Directus CMS (Self-hosted)

Directus requires shared backend infrastructure.

Good:

 VPS1 Directus
 VPS2 Directus
 |
 |
Shared PostgreSQL

Bad:

VPS1 -> PostgreSQL A
VPS2 -> PostgreSQL B

Data immediately diverges.

Any self-hosted analytics services

Same requirement. Both instances should point to the same database.

Otherwise:

Visitors on VPS1
Visitors on VPS2

are counted separately.

Scenario 2: Same Tunnel, Completely Different Services

Suppose:

VPS1
 ├─ Express
 ├─ Directus
 └─ Umami

VPS2
 ├─ Grafana
 └─ Prometheus

and both use the same tunnel credentials. At first glance this seems convenient. Unfortunately, it introduces a major problem.

Why Different Services Break Shared Tunnels

Assume the tunnel config contains:

ingress:
 - hostname: app.example.com
 service: http://express:3000

 - hostname: grafana.example.com
 service: http://grafana:3000

Cloudflare sees:

Tunnel
├─ Connector VPS1
└─ Connector VPS2

A request arrives:

https://app.example.com

Cloudflare may choose either connector.

Case A:

Cloudflare
 |
 VPS1
 |
 Express

Success.

Case B:

Cloudflare
 |
 VPS2
 |
 Express ?

Container doesn't exist.

Result:

502 Bad Gateway

or

Connection Refused

This is one of the most common tunnel architecture mistakes.

Important Rule

Every connector attached to a tunnel should be able to satisfy every ingress rule associated with that tunnel.

If not:

• Routing becomes unpredictable

• Some requests fail

• Troubleshooting becomes difficult

Scenario 3: Same Tunnel Credentials, Different Config Files

Another subtle case:

Server A:

ingress:
 - hostname: app.example.com
 service: http://express:3000

Server B:

ingress:
 - hostname: grafana.example.com
 service: http://grafana:3000

But both use:

same tunnel UUID
same credentials file

This configuration is dangerous. Cloudflare does not maintain a mapping of:

app.example.com -> VPS1 only
grafana.example.com -> VPS2 only

The tunnel is the routing object. The connector is merely an endpoint attached to that tunnel. As a result:

Cloudflare
 |
 Tunnel
 |
+---+---+
| |
A B

Traffic can arrive at either connector.

Recommended Architecture for Different Services

Instead of:

One Tunnel
 |
+---+---+
| |
VPS1 VPS2

Use:

Tunnel A Tunnel B
 | |
 VPS1 VPS2

Example:

prod-tunnel
 ├─ app.example.com
 ├─ cms.example.com
 └─ analytics.example.com

monitoring-tunnel
 ├─ grafana.example.com
 └─ prometheus.example.com

This is cleaner, safer, and easier to operate.

Scenario 4: Using Tunnel as a Horizontal Scaling Mechanism

Can Tunnel provide horizontal scaling? Technically yes, but only under certain conditions.

Requirements:

VPS1
 ├─ Express
 ├─ Directus
 └─ Umami

VPS2
 ├─ Express
 ├─ Directus
 └─ Umami

And:

Shared PostgreSQL
Shared Redis
Shared Object Storage

Architecture:

 Cloudflare
 |
 Tunnel
 |
 +-----------+-----------+
 | |
 VPS1 VPS2
 | |
 +-----------+-----------+
 |
 Shared Database

This can work surprisingly well for small and medium deployments.

Scenario 5: Docker External Networks Across VPSes

Many people create:

networks:
 tunnel:
 external: true

and assume it can span servers. It cannot. Docker bridge networks are local to a host.

This works:

VPS1
 ├─ cloudflared
 ├─ express
 └─ directus

because all containers share the same Docker network.

This does not work:

VPS1 cloudflared
 |
 |
 X
 |
 |
VPS2 directus

Docker networking does not magically connect containers across hosts.

You need:

• Overlay networking

• Kubernetes

• Docker Swarm

• Tailscale

• WireGuard

• Service mesh

or another cross-host networking solution.

Scenario 6: Real Load Balancing

Eventually you may need:

• Health checks

• Weighted traffic

• Regional routing

• Traffic steering

• Session stickiness

At that point use:

Cloudflare Load Balancer

Architecture:

 Client
 |
 Cloudflare LB
 |
+------+------+
| |
VPS1 VPS2

Unlike Tunnel alone, the Load Balancer actively understands backend health and routing policies.

Recommended Production Architecture

For a modern self-hosted stack:

VPS1
 ├─ cloudflared
 ├─ Express
 ├─ Directus

VPS2
 ├─ cloudflared
 ├─ Express
 ├─ Directus

Shared:
 ├─ PostgreSQL
 ├─ Redis
 └─ Object Storage

Monitoring:

Separate Tunnel
 |
 Grafana
 Prometheus

This provides:

• High availability

• Connector redundancy

• Basic traffic distribution

• Horizontal scaling

• Simpler operations

without introducing unnecessary complexity.

Final Takeaway

Cloudflare Tunnel is excellent for exposing services securely and providing connector-level redundancy. Multiple connectors attached to the same tunnel can improve availability and distribute traffic, but they are not a replacement for a dedicated load balancer.

The most important rule is simple:

If multiple servers share a tunnel, every server should be capable of serving every hostname defined by that tunnel.

If servers host different workloads, create separate tunnels.

If servers host identical workloads backed by shared state, multiple connectors can provide a lightweight and effective high-availability architecture.