A self-hosted app behind Cloudflare Tunnel usually works fine until the day it does not. A friend cannot join the game server. A mail client refuses the connection. A media library that has grown from a personal project into something a dozen people use starts to feel like it is testing a limit Cloudflare never fully settled. At that point the fix is not to tear the tunnel down. It is to add a routed IPv4 for the one service that has outgrown it, and move that service over without anyone noticing a gap.
This is the actual migration: what to decide before touching anything, the real order of the technical steps, and how the service stays reachable the entire time, including the moment Cloudflare Tunnel gets switched off for good.
Decide what actually needs to move
Not every hostname behind cloudflared needs to move. A web app or an API that only ever receives HTTP and HTTPS requests has no reason to leave Cloudflare Tunnel; the free, anonymous, TLS-terminated path stays genuinely convenient for that traffic. The service worth migrating is the specific one that has hit a real wall: a UDP game server, a mail server, a VPN endpoint, or continuous high-bandwidth media that raises the terms-of-service question covered in Cloudflare Tunnel vs. a routed IPv4 for self-hosting.
Before ordering anything, check the current cloudflared configuration for that service's public hostname entry and confirm whether its DNS record is a proxied Cloudflare CNAME or a route created with cloudflared tunnel route dns, which "creates a DNS CNAME record hostname that points to the tunnel." Cloudflare: Tunnel useful commands That record is exactly what gets replaced later, and knowing its current type avoids surprises during the cutover.
What changes once Cloudflare is out of the path
Two things move onto the server itself, and both are worth naming honestly before starting. First, TLS. Cloudflare Tunnel lets Cloudflare's edge issue and terminate the certificate, so the origin server never handles it. A routed IPv4 exposes that server directly, so it becomes responsible for its own certificate, typically through Let's Encrypt behind Caddy, or another ACME client wired into the same reverse proxy already running.
Second, edge filtering. Cloudflare's proxy absorbs a large share of volumetric abuse before it reaches the origin. A routed IPv4 removes that specific layer unless the new address sits behind its own filtering, which is why Taipan Transit applies its own DDoS protection and Netbait-based filtering to every routed address by default rather than leaving it exposed raw. Neither change is a reason to avoid the migration. They are simply the two things to have ready before the cutover, not after.
Step-by-step migration without downtime
- Order the routed IPv4 and bring up the new tunnel. WireGuard is the fastest to configure. Leave the existing
cloudflaredprocess completely untouched; the two tunnels do not conflict, since one proxies HTTP at Cloudflare's edge and the other routes an IP address at the network layer. - Test the new path on a separate hostname first. Point a temporary subdomain, or a local hosts file entry during early testing, at the new IPv4 and confirm the service answers correctly through it, side by side with the live Cloudflare-fronted hostname still serving real visitors.
- Lower the DNS TTL on the record that will move. A short TTL set some time ahead of the cutover, and given time to expire on caching resolvers everywhere, is what turns the eventual switch into a clean handoff instead of a slow, inconsistent rollout.
- Cut the DNS record over. Replace the Cloudflare Tunnel CNAME with an A record pointing at the routed IPv4, during a low-traffic window, then watch resolvers pick up the new answer as the lowered TTL expires.
- Confirm the service is reachable exclusively through the new address for a full day or more before removing anything on the Cloudflare side. This window is what catches a resolver or a client that cached the old answer longer than expected.
- Decommission the tunnel with
cloudflared tunnel delete <name> -fonce nothing depends on it. Cloudflare's own command reference does not describe this also removing the DNS record it created, so that CNAME needs to be deleted by hand in the dashboard afterward. Cloudflare: Tunnel useful commands
| Stage | Cloudflare Tunnel | Routed IPv4 |
|---|---|---|
| Before the cutover | Serving all production traffic | Running, reachable only on the test hostname |
| During the DNS switch | Still up, unused by new lookups | Now the answer for the migrated hostname |
| After confirmation | Deleted with cloudflared tunnel delete -f | Serving all production traffic for that service |
Taipan Transit routes a dedicated public IPv4 through WireGuard, GRE, or IPsec starting at €2 per month for the tunnel and €0.70 per month per address, filtered by default, on its pricing page. Order the address early so it can run in parallel while the DNS TTL winds down.
Common mistakes during the cutover
The most frequent one is skipping the TTL step and cutting the record over immediately. Some resolvers hold onto the previous CNAME well past its nominal expiry, so a small fraction of visitors keep hitting the old path for longer than expected. Lowering the TTL a day or more ahead of the change, then waiting for it to actually take effect, removes that risk almost entirely.
The second is forgetting that the origin's firewall rules, written for the old CGNAT or NAT setup, do not automatically apply to the new routed address. Confirm the exact ports the migrated service needs are open on the interface tied to the new IPv4 before the DNS cutover, not after a visitor reports a timeout.
Frequently asked questions
Do I need to move every service off Cloudflare Tunnel at once?
No. Migrate one service at a time. Web apps that only need HTTP or HTTPS can stay on Cloudflare Tunnel indefinitely; move only the service that has hit a protocol or policy limit.
Will visitors see any downtime during the cutover?
Not if the new path is tested in parallel first and the DNS TTL is lowered ahead of time. The record only changes once the routed IPv4 has already been verified to work, so the switch is a DNS answer change, not an outage.
Who handles the TLS certificate after moving to a routed IPv4?
The origin server does. Cloudflare Tunnel terminates TLS at Cloudflare's edge, but a routed IPv4 exposes the server directly, so it needs its own certificate, typically issued through Let's Encrypt via Caddy or another ACME client.
Does deleting a Cloudflare Tunnel also remove the DNS record it created?
Not automatically. Cloudflare's own command reference for cloudflared tunnel delete does not describe it removing the associated DNS record, so that CNAME has to be removed by hand in the Cloudflare dashboard afterward.