How to Set Up Remote File Transfer with Cloudflare Tunnels

The Core Argument: You Shouldn't Need to Pay for Remote File Access

Accessing your own files on your own computer from your own phone should be free. That's the position, and I'll argue it with specifics.

Cloud storage services charge monthly fees to let you access your files from anywhere. Google Drive, iCloud, Dropbox: they all work the same way. Upload your file to their server, download it on another device. You're paying for server storage and bandwidth to shuttle data between your own devices. The files are yours, the devices are yours, but the pipe between them belongs to someone else.

Cloudflare's quick tunnel service (trycloudflare.com) offers an alternative. It creates a temporary public URL that routes directly to a server running on your machine. No file uploads to a third party. No storage fees. No monthly subscription. Your data goes from your phone through Cloudflare's network to your PC, and that's it. Cloudflare doesn't store your files; it routes packets.

I built remote transfer into OpenDrop using Cloudflare tunnels because the free tier needed to work for everyone, not just people willing to pay. Same-network transfers are fast and free. Remote transfers through tunnels are slower but still free. That combination covers most people's needs without a subscription.

What Cloudflare Quick Tunnels Actually Do

A quick tunnel (sometimes called a TryCloudflare tunnel) works differently from a traditional VPN or port forward. You don't open ports on your router. You don't configure firewall rules. You don't need a static IP address.

Here's the mechanism: the cloudflared binary runs on your machine and establishes an outbound connection to Cloudflare's edge network. Cloudflare assigns a random URL (something like https://random-words.trycloudflare.com) that routes incoming requests through their network to your machine via that outbound connection. Because the connection is outbound from your machine, it works behind NAT, behind firewalls, behind corporate networks, behind most things that would block inbound connections.

The tunnel provides TLS encryption automatically. The random URL uses HTTPS. Traffic between the external client (your phone) and Cloudflare's edge is encrypted. Traffic between Cloudflare's edge and your machine travels through the established tunnel connection. Your local server can run plain HTTP because the encryption happens at Cloudflare's layer.

Quick tunnels are ephemeral. When the cloudflared process stops, the URL dies. No leftover infrastructure, no DNS records to clean up, no orphaned connections. Start the tunnel, use it, stop it. The next time you start it, you get a new random URL.

Why Tunnels Beat the Alternatives

The traditional ways to access a machine remotely are all worse for this specific use case.

Port forwarding requires router access and configuration. You log into your router, forward port 8000 (or whatever) to your PC's local IP, and hope your ISP doesn't block it. Many ISPs do block inbound connections on residential plans. If your router reboots and assigns a new local IP via DHCP, the forward breaks. You also need to know your public IP, which changes periodically unless you pay for a static one. And you've now exposed a port on your home network to the entire internet.

VPN solutions (Tailscale, WireGuard, OpenVPN) work well but add complexity. You install a VPN client on every device, configure the network, manage keys. For a technical user running a homelab, this is fine. For someone who just wants to grab a file from their home PC while at a coffee shop, it's massive overkill.

Cloud upload/download means your files transit through someone else's server and sit there until you delete them. Bandwidth and storage cost money. Upload speed from a home connection is typically much slower than download speed, so pushing a large file to the cloud takes disproportionately long.

Cloudflare tunnels sidestep all of these problems. No router configuration, no VPN client, no cloud storage. One binary (cloudflared) opens a connection outward, Cloudflare handles routing inward. The tunnel is temporary, the URL is random, and nothing persists after you close it.

The 5MB Ceiling and What It Means in Practice

Cloudflare's quick tunnel infrastructure imposes a limit on HTTP request body size. In practice, this means you can't send a 500MB file as a single HTTP request through the tunnel. The request gets rejected, and the error message doesn't clearly explain why.

I spent a fair amount of time debugging this when first building OpenDrop's remote transfer. The fix is chunking: split the file into pieces small enough to fit within the limit, send each piece as a separate HTTP request, and reassemble on the receiving end. OpenDrop uses 5MB chunks, which sit comfortably under the ceiling.

Chunking works, but it's slower. Each 5MB chunk involves a full HTTP round-trip: TCP connection (or reuse), TLS handshake (cached after the first), request headers, 5MB payload, server acknowledgment. That per-chunk overhead accumulates. In practice, free remote transfers through the tunnel run at roughly 8 Mbps (about 1 MB/s).

For context, a 500MB file at 8 Mbps takes about 8 minutes. A 2GB file takes about 33 minutes. Workable for most files, but not great for large video transfers. There's no hard file size cap (you can send a 10GB file in 5MB chunks), just a throughput ceiling.

The chunking limitation is inherent to Cloudflare's free tunnel service, not to OpenDrop specifically. Any tool that uses quick tunnels for file transfer hits the same wall. The question is whether the tool handles it gracefully (automatic chunking, retry on failure) or breaks when files exceed the limit.

How OpenDrop Automates the Entire Thing

You could set up a Cloudflare tunnel manually. Download cloudflared, run it from the command line, configure your local server, share the URL with your phone, and build a client that sends files through it. Thousands of developers have done exactly this for various projects.

OpenDrop automates every step. Here's what happens when you launch the desktop app:

1. The HTTP server starts on 0.0.0.0:8000 with HMAC-SHA256 request signing enabled.
2. mDNS advertisement begins, broadcasting _opendrop._tcp.local. so local devices can find the server.
3. The cloudflared binary is located (bundled in the app for Mac App Store builds, or downloaded automatically on first launch for other platforms). OpenDrop detects the OS and architecture and downloads the correct binary from Cloudflare's GitHub releases.
4. A quick tunnel is started, connecting the local server to Cloudflare's network.
5. When the tunnel connects, the random URL is captured and displayed as a QR code on the dashboard.

On the mobile side, the app scans for the mDNS service on the local network. If it finds the server locally, it connects directly. If not (different network), you scan the QR code or enter the tunnel URL manually. The app detects the connection type and adjusts the transfer mode: streaming for LAN, 5MB chunks for the tunnel.

The CLI works the same way. Running opendrop serve starts the server, connects the tunnel, and prints the URL and shared secret to the terminal. No GUI needed. The server stays running until you press Ctrl+C.

None of this requires a Cloudflare account. Quick tunnels are a free, anonymous service. No API keys, no configuration, no sign-up. Cloudflare offers this because it drives adoption of their broader platform, and the resource cost of quick tunnels is low enough to subsidize.

When Tunnels Aren't Enough

The 8 Mbps throughput ceiling is the main limitation. For someone who routinely transfers gigabytes of data remotely (raw video files, full photo library dumps, large backup archives), the wait times add up.

OpenDrop Pro offers a faster alternative for this scenario: a Fly.io-based relay server using WebSocket with binary frames. Instead of chunked HTTP through Cloudflare, the data streams as binary WebSocket frames through the relay. No 5MB limit per request, no chunking overhead. Pro relay transfers typically run at 30-50+ Mbps, which is 4-6x faster than the free tunnel. We originally used base64-encoded JSON for the relay protocol and discovered the 33% encoding overhead was eating a significant chunk of throughput. Switching to binary frames fixed that.

The relay isn't free because Fly.io charges for bandwidth and compute. The Pro subscription covers that cost. For users who need fast remote transfers regularly, it's worth it. For users who only need remote transfer occasionally, the free Cloudflare tunnel is fine.

My position remains: basic remote file access between your own devices should be free. OpenDrop's free tier delivers that through Cloudflare tunnels. It's slower than LAN, slower than Pro, but it works from anywhere with an internet connection and costs nothing. The Pro tier exists for people who need more speed, not as a gate that locks basic functionality behind a paywall.

Cloudflare's quick tunnel service is one of the most underappreciated pieces of free infrastructure available to developers. It solves the NAT traversal problem, provides free TLS, and requires zero configuration. For file transfer specifically, the 5MB body limit forces chunking, but the alternative (no remote transfer at all, or paid cloud storage) is worse. A free, chunked, encrypted tunnel to your own machine is a good deal.