The first real problem you hit when setting up a home server is access. Getting files off your server while you’re sitting at home is easy — everything is on the same network. But what about from work, or a hotel, or your phone on mobile data? Suddenly you need a way to reach into your home network from the outside, and that’s where things get interesting.

The instinct most people have is to open a port on their router. Point port 443 at your server, let traffic through, job done. It works, but it means your server is now reachable from the public internet. Anyone scanning IP addresses — and plenty of automated tools do exactly that — can find it and start probing. You’re relying entirely on your application’s login screen as your only line of defence.

There is a better way, and it hinges on a single question: does your server need to wait to be found, or can it go and make the connection itself?

The answer, it turns out, is that it can reach out. And that changes everything.

The tunnel model#

A Cloudflare Tunnel works like this. A small piece of software runs on your server and maintains a persistent outbound connection to Cloudflare’s network. When someone wants to access your server, they hit a domain you control, Cloudflare receives that request, and relays it inbound along the connection your server already opened. The response comes back the same way.

At no point does anything on the internet initiate a connection to your server. The connection always starts from your end.

Think of it like a phone call you make out. Someone can talk back to you on that call, but they couldn’t have reached you by dialling in. They can only respond on the channel you opened. No one can knock on your door because your door doesn’t face the internet. It’s not that there’s a strong lock on it. The door simply doesn’t exist from the outside.

This isn’t just a conceptual nicety. It means there are no open ports on your router. It means your home IP address is never exposed. It means automated scanners have nothing to find.

What Cloudflare actually does here#

Cloudflare sits in the middle, handling the public-facing side of things. SSL certificates, DDoS protection, bot filtering — all of that is handled before a request ever gets anywhere near your server. Your server just sees a local request from the tunnel daemon and responds to it. It has no idea it’s talking to the outside world.

This does mean you’re trusting Cloudflare to handle your traffic. That’s a reasonable trade-off for a home setup — they’re a large, well-established infrastructure company — but it’s worth understanding rather than ignoring. You’re not replacing trust with no trust. You’re choosing who to trust, and why.

How the domain fits in#

This was one of those moments where the explanation finally made the underlying model clear.

The domain, something like cloud.yourdomain.com, isn’t a route to your server. It’s a label on Cloudflare’s side. When your server establishes the tunnel, Cloudflare says: anything that comes in for this domain, I’ll put onto that connection. The server never knows or cares what the domain is. It just keeps the tunnel open, and Cloudflare does the routing.

That also means adding another service is straightforward. A new subdomain, a new entry in the tunnel config pointing to a different local port, and Cloudflare handles the rest. One tunnel, one domain, as many services as you need.

What this protects against, and what it doesn’t#

The tunnel handles the network exposure problem well. Nobody can reach your server directly, your IP is hidden, and you’re not managing SSL certificates yourself.

What it doesn’t do is replace sensible application security. Strong passwords, keeping software updated, understanding what’s actually running — those still matter. The tunnel gets you to your front door safely. What’s behind the door is still your responsibility.

For a home setup this is a reasonable and well-understood approach. Understanding why it works is what makes it trustworthy, rather than just hoping it does.