Deploy Cloudflared
A lightweight Cloudflare Tunnel connector for securely exposing services.
cloudflared
Just deployed
Deploy and Host Cloudflare Tunnel on Railway
Cloudflare Tunnel (cloudflared) provides a secure outbound connection between Railway services and Cloudflare's global network without exposing the origin service directly to the public internet.
This template deploys the official Cloudflare cloudflared container as a lightweight, remotely managed Tunnel connector.
About Hosting Cloudflare Tunnel
This template runs the official cloudflare/cloudflared Docker image on Railway.
Unlike a traditional reverse proxy, Cloudflare Tunnel does not require an inbound public port. The cloudflared connector establishes an outbound encrypted connection from Railway to Cloudflare, allowing traffic from a configured hostname to reach services through the tunnel.
Tunnel configuration, public hostnames, and routing are managed remotely from Cloudflare. A Cloudflare Tunnel token is required to connect the Railway deployment to an existing tunnel.
Because the connector is stateless, no database, Redis instance, or persistent volume is required.
Common Use Cases
- Securely expose Railway services through Cloudflare Tunnel
- Keep application services private while providing controlled public access
- Route custom domains to services on Railway
- Add Cloudflare protection in front of private applications
- Expose internal dashboards and development tools
- Connect multiple hostnames to different services through one tunnel
- Avoid exposing application services directly through public networking
Dependencies for Cloudflare Tunnel Hosting
- Cloudflare account — Used to create and manage the tunnel
- Cloudflare Tunnel token — Authenticates the
cloudflaredconnector - Origin service — The application or endpoint that Cloudflare Tunnel will route traffic to
No PostgreSQL, Redis, persistent volume, or additional database service is required.
How It Works
Internet
│
▼
app.example.com
│
▼
┌──────────────────┐
│ Cloudflare Edge │
└────────┬─────────┘
│
Encrypted Tunnel
│
▼
┌──────────────────┐
│ cloudflared │
│ Railway │
└────────┬─────────┘
│
Railway Private Network
│
▼
┌──────────────────┐
│ Origin Service │
│ app:PORT │
└──────────────────┘
The Railway cloudflared service does not need its own public domain or exposed HTTP port.
Create a Cloudflare Tunnel
Before deploying the template:
- Open the Cloudflare Dashboard.
- Navigate to Networking → Tunnels.
- Create a new Cloudflare Tunnel.
- Select Cloudflared as the connector.
- Choose the Docker deployment option.
- Copy the generated Tunnel token.
- Deploy this Railway template.
- Add the Tunnel token to the required Railway variable.
The Tunnel token is sensitive and should be treated as a secret.
Configure the Origin Service
After the connector is online, configure a public hostname from the Cloudflare Tunnel dashboard.
For example, if a Railway service is named:
n8n
and listens on:
5678
the Cloudflare Tunnel origin can use Railway private networking:
http://n8n.railway.internal:5678
The resulting traffic flow becomes:
n8n.example.com
│
▼
Cloudflare
│
▼
Cloudflare Tunnel
│
▼
cloudflared
│
▼
n8n.railway.internal:5678
This allows the origin application to remain private while Cloudflare handles external traffic.
Multiple Services
A single Cloudflare Tunnel can route different hostnames to different Railway services.
For example:
automation.example.com
→ http://n8n.railway.internal:5678
status.example.com
→ http://uptime-kuma.railway.internal:3001
api.example.com
→ http://api.railway.internal:8080
Each hostname and origin mapping can be configured from the Cloudflare Tunnel dashboard without modifying the cloudflared Railway service.
Networking
The cloudflared service establishes outbound connections to Cloudflare.
Therefore, the connector itself does not require:
- Railway Public Networking
- A Railway-generated public domain
- HTTP or TCP port exposure
- TCP Proxy
- Persistent storage
Origin services can communicate with cloudflared through Railway's private network.
Persistent Storage
No persistent Railway volume is required.
Remotely managed Cloudflare Tunnels authenticate using a Tunnel token rather than locally stored tunnel credentials, making the connector suitable for stateless container deployments.
Security
Keep the Cloudflare Tunnel token private.
Anyone with access to a valid Tunnel token may be able to run another connector for that tunnel.
For production deployments:
- Store the Tunnel token as a Railway secret variable
- Do not commit Tunnel tokens to Git repositories
- Keep origin services private when public Railway networking is unnecessary
- Use Cloudflare Access when authentication or identity-based access control is required
- Restrict access to internal dashboards and administrative applications
Cloudflare Tunnel vs Traditional Exposure
| Feature | Cloudflare Tunnel | Railway Public Domain | Traditional Reverse Proxy |
|---|---|---|---|
| Public inbound port on origin | ❌ | ✅ | ✅ |
| Outbound-only connector | ✅ | ❌ | ❌ |
| Custom hostname | ✅ | ✅ | ✅ |
| Cloudflare edge protection | ✅ | Optional | Optional |
| Private Railway origin | ✅ | ❌ | ⚠️ |
| Persistent volume required | ❌ | ❌ | Usually ❌ |
| Separate reverse proxy configuration | ❌ | ❌ | ✅ |
| Zero Trust integration | ✅ | ❌ | Depends |
Cloudflare Tunnel is particularly useful when the goal is to expose an application through Cloudflare while keeping the Railway origin service off the public internet.
Why Deploy Cloudflare Tunnel on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
By deploying Cloudflare Tunnel on Railway, you can securely connect private Railway services to Cloudflare's network while keeping your application infrastructure simple and reducing unnecessary public exposure.
Template Content
cloudflared
cloudflare/cloudflared:latestTUNNEL_TOKEN
Cloudflare remotely-managed Tunnel token
