A Cloudflare Tunnel lets you expose a local server, app, or internal tool to the internet, or just to your own team, without opening a single inbound firewall port. Instead of punching a hole through your network for the outside world to reach in, a lightweight connector on your machine makes an outbound connection to Cloudflare, and Cloudflare routes traffic to it from there. If you’re setting one up for the first time, there’s a good chance the guide you find first describes the older, CLI-only method, this Cloudflare tunnel guide walks through how to create a Cloudflare tunnel using Cloudflare’s current, officially recommended dashboard-based cloudflare tunnel setup instead, which is both more current and genuinely easier for a first attempt.
What a Cloudflare Tunnel Actually Does
Before the steps, it helps to understand the actual mechanism. Your server, the origin server actually running your application, runs a small piece of software called cloudflared, which opens an outbound-only connection to Cloudflare’s network, no inbound port needs to be open on your firewall at all, since the connection always originates from your side. Once that connection exists, you tell Cloudflare where to route incoming requests: to a specific hostname pointing at a local service (publishing an application), or into a private network entirely (for internal-only access via Zero Trust policies). This is the same underlying mechanism covered briefly in our broader Cloudflare Zero Trust and WARP setup guide, this piece goes much deeper into the tunnel-creation process specifically.
Prerequisites
- A Cloudflare account with a domain already added and its nameservers pointed to Cloudflare
- Administrative access to the server or machine hosting the service you want to expose
- Outbound network access on port 7844 (TCP/UDP), most networks allow this by default, but verify connectivity first if your network has a restrictive firewall
Step 1: Create the Tunnel in the Cloudflare Dashboard
Log in to the Cloudflare tunnel dashboard and navigate to Networking > Tunnels. Select Create a tunnel, then choose Cloudflared as the connector type, this creates what Cloudflare calls a remotely managed tunnel, configured through the dashboard rather than a local file. Give your tunnel a clear, descriptive name, something like office-app-tunnel rather than a generic label, since you may end up managing several tunnels over time and want to tell them apart at a glance.
Step 2: Install the Connector
After naming your tunnel, Cloudflare generates an installation command specific to your operating system, built around a unique tunnel token tied to this specific tunnel. Select your platform (Windows, macOS, or a specific Linux distribution) and copy the exact command shown, a generic copy-pasted command from another source, with a different tunnel token, simply won’t authenticate.
For Linux, the install typically looks like:
curl -L https://pkg.cloudflare.com/install.sh | sudo bash
sudo apt install cloudflared
Run the generated command on the server hosting your application, then return to the dashboard and wait for the connection status to show as active, this confirms the outbound connection from your server to Cloudflare succeeded.
Step 3: Publish Your Application
With the tunnel connected, you need to tell Cloudflare what to actually route traffic to. In the tunnel’s Public Hostname settings, add:
- Subdomain: whatever you want people to type (e.g., app)
- Domain: your domain already added to Cloudflare
- Service Type: HTTP or HTTPS, matching what your local service actually runs
- URL: the local address of your service (e.g., localhost:3000)
Once saved, Cloudflare automatically creates the necessary DNS CNAME record behind the scenes, you don’t need to manually configure DNS yourself, which is one of the genuine conveniences of the dashboard-based approach over the older CLI method.
Step 4: Test the Connection
Visit your new hostname (app.yourdomain.com in the example above) in a browser. If it loads your local service correctly, the tunnel is working. If it doesn’t, the most common causes are a mismatched service type (HTTP vs. HTTPS) or the local service not actually running on the port specified, check both before assuming the tunnel itself is broken.
Step 5: Add Zero Trust Access Control (Recommended)
A tunnel alone makes your service reachable, it doesn’t restrict who can reach it. For anything beyond a public-facing website, adding a Zero Trust access policy is worth doing immediately, not as an afterthought:
- Go to Access > Applications > Add an application > Self-hosted
- Enter your published hostname as the application domain
- Create a policy, for example, Action: Allow, Include: emails ending in your organization’s domain
This adds an authentication gate in front of the tunnel, so only people who pass your policy’s conditions can reach the service at all, rather than anyone who happens to find or guess the URL. You can layer multiple conditions into one policy, requiring both a specific email domain and a managed device, for instance, for stricter access than a single condition alone provides.
Alternative: The CLI Method (For Advanced or Scripted Setups)
The dashboard method above covers most beginner use cases, but Cloudflare also supports a CLI-only, “locally-managed” tunnel approach, useful for automated or scripted deployments:
cloudflared tunnel login
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel my-hostname.example.com
cloudflared tunnel run my-tunnel
This method requires manually maintaining a config.yml file defining ingress rules, the mapping between hostnames and local services, and manually running the DNS routing command. A minimal ingress configuration looks like this:
tunnel: <TUNNEL_ID>
credentials-file: /root/.cloudflared/<TUNNEL_ID>.json
ingress:
  – hostname: app.example.com
    service: http://localhost:3000
  – service: http_status:404
The final catch-all rule (http_status:404) matters, without it, requests that don’t match any defined hostname will cause the tunnel to fail rather than simply returning a not-found response. This is more manual setup than the dashboard method most beginners should start with, but it’s the right choice once you’re managing tunnel configuration as code alongside the rest of your infrastructure.
Connecting a Private Network (Instead of Publishing Publicly)
If your goal is internal team access to a private resource, not exposing something to the public internet at all, choose Connect a private network instead of Publish an application in Step 3. This routes traffic into your private network through the tunnel, reachable only by devices running the Cloudflare Zero Trust client and passing your access policies, covered in more depth in our Zero Trust and WARP setup guide.
Common Mistakes
Copying an installation command from an old guide or a different tunnel: Each tunnel’s install command contains a unique token, reusing one from a different tunnel or an outdated tutorial simply won’t authenticate correctly.
Forgetting to add an Access policy: A working tunnel with no access control means anyone who discovers the hostname can reach your service, this is a genuinely common oversight, not a rare misconfiguration.
Mismatching the service type: Setting HTTPS when your local service actually runs plain HTTP (or vice versa) is one of the most common reasons a freshly created tunnel doesn’t load correctly.
Assuming DNS propagation delays are a tunnel problem: Occasionally a new hostname takes a few minutes to resolve, this is normal DNS behavior, not a sign the tunnel itself failed.
The Bottom Line
This Cloudflare remotely managed tunnel guide comes down to a genuinely approachable process once you’re following the current, dashboard-based method rather than an older CLI-only guide: create the tunnel, install the connector, publish your application or connect a private network, and add an access policy before calling it done. The most common mistakes, copying the wrong install command, skipping access control, mismatching HTTP and HTTPS, are all avoidable with a careful first pass through the steps above.
Setting This Up for a Real Organization
A single tunnel for a personal project or small team is straightforward to configure yourself using this guide. Rolling tunnels out across an entire organization, with consistent naming, centralized access policies, and integration into a broader security and compliance program, is real infrastructure work, closely related to the continuous monitoring discipline that matters for any production system. A tunnel is ultimately routing external requests to an internal service, the same underlying problem covered from the architecture side in our Middleware vs API Gateways comparison, worth reading if you’re deciding how tunnels fit into a larger system, not just a single exposed app. If you want this set up correctly at scale, that’s the kind of work we do.
Frequently Asked Questions
Do I need to open any firewall ports to use a Cloudflare Tunnel?Â
No, that’s the core benefit. The connector makes an outbound-only connection to Cloudflare, so no inbound port needs to be opened on your firewall at all.
What’s the difference between a remotely-managed and locally-managed tunnel?Â
A remotely-managed tunnel is configured through Cloudflare’s dashboard and is the current recommended default. A locally-managed tunnel is configured entirely through the CLI and a local config file, more manual, but useful for scripted or automated deployments.
Is Cloudflare Tunnel free to use?Â
Yes, Cloudflare Tunnel is available on Cloudflare’s free tier, making it accessible for personal projects and small teams without a paid plan requirement.
Can I use a Cloudflare Tunnel without a domain?Â
For publishing an application publicly, you need a domain added to Cloudflare. Private network routing has more flexibility, but a domain is still generally required to complete initial account setup.
Why isn’t my Cloudflare Tunnel hostname loading?Â
Most commonly a mismatched service type (HTTP vs. HTTPS) or the local service not actually running on the specified port, verify both directly before assuming the tunnel connection itself has failed.
Should I add Zero Trust Access to every tunnel?Â
For anything beyond a genuinely public-facing site, yes, a tunnel without an access policy is reachable by anyone who finds the hostname, which defeats much of the security benefit of using Zero Trust in the first place.
How to create a Cloudflare tunnel step by step if I’ve never used Cloudflare before?Â
Follow the five steps above in order, create the tunnel in the dashboard, install the connector, publish your application, test it, then add an access policy. Cloudflare tunnel setup for beginners genuinely doesn’t require more than that for a first working tunnel.
What’s the real difference between Cloudflare Tunnel and the cloudflared CLI?Â
They’re not separate products, cloudflared is the connector software both methods use. “Cloudflare Tunnel” via the dashboard configures that connector remotely; the cloudflared CLI method configures it locally through a config file. Comparing Cloudflare tunnel vs cloudflared CLI is really a question of dashboard-managed versus file-managed configuration, not two different tools.
How to expose a local server with Cloudflare Tunnel specifically?Â
Follow Step 3 above: in the tunnel’s Public Hostname settings, point a subdomain at your local service’s address and port. That’s the complete mechanism for exposing any local server through the tunnel.
Does Cloudflare Tunnel actually work without opening any firewall ports?Â
Yes, this is the core design goal. A cloudflare tunnel without opening firewall ports is the default behavior, not an advanced configuration, since the connector always initiates an outbound-only connection.