Publishing a Home Server Through a Cloudflare Tunnel

How a web app on a personal computer became reachable from the internet without opening a router port

Vishnu Vardhan · 11 October 2026

Why the router blocks visitors

Every device at home has a private address, such as 192.168.1.20. The router shares one public address among them. When the computer opens a connection, the router rewrites the source address and records the mapping. This is network address translation (NAT).

Take one request. The computer connects to 93.184.216.34 on port 443, the standard HTTPS port, from local port 51514. The router records that mapping. A reply that matches it returns to 192.168.1.20. A packet that matches no mapping is discarded, so a visitor's first packet never reaches the computer.

Why not port forwarding

The design had to leave the router unchanged, serve visitors by name over HTTPS, keep the model private, and serve the page and the API from one origin. Port forwarding sends one port from the router to the computer. It works, and it is the usual answer. But the computer then answers anyone who scans the address, needs a certificate for a domain name, and breaks when the address changes. Many residential providers also use carrier-grade NAT, which shares one address among many customers. Port forwarding cannot work on those connections.

A tunnel reverses who opens the connection. The computer calls out, and visitors ride that call.

GitHub Pages could host the static page but not the API. The API would still need a tunnel, and the two would sit on different origins. Cloud hosting breaks the privacy requirement. The tunnel was the only option that met every requirement.

How the tunnel works

This setup uses two parts of Cloudflare Tunnel. The first is cloudflared, a connector program installed as a Windows service on the computer. The second is tunnel routing: a public hostname that Cloudflare maps to a local service. Here the route points the hostname at the Vite preview server on 127.0.0.1:4173. Vite forwards /api to Spring, so one route serves both.

cloudflared opens an encrypted session outward to Cloudflare. The router already tracks outbound connections, so it needs no change. When a visitor arrives, Cloudflare sends the request down the session the computer opened.

The session has three layers. TCP moves the bytes. TLS, the encryption behind HTTPS, protects them. A tunnel protocol carries many requests over one connection. The connector opens several such connections to different Cloudflare data centers, so one failing path does not take the site down. This article does not test failover.

Three systems, one job each

Three systems are involved. The edge is Cloudflare's server nearest each visitor. It receives every connection before the computer does.

What one request looks like

Loading the page and sending a chat message share their first hops. They differ at Vite. Loading the page ends there. A chat message continues to Spring.

The page and the API share one hostname, so the browser treats the call to /api as same-origin. Browsers block cross-origin calls unless the server allows them through CORS, which needs matching headers on both sides. One hostname avoids that. The cost is that Vite's /api rule must be correct.

Known gaps

A route is as wide as what sits behind it. The page route exposes the page and, through Vite, the API. A route straight to Spring would skip Vite's host check, which is why the setup keeps one route. Still open, in priority order:

1. Bind Spring to 127.0.0.1, so only the local proxy can reach the API.
2. Add Cloudflare Access before sharing the link widely.
3. Rate-limit the chat. Each request uses the computer's CPU and GPU, and anyone with the link can send prompts.
4. Replace the Vite preview server with a production reverse proxy such as Caddy. Vite's preview server is for a demo on one machine.
5. Confirm the route service type. The dashboard shows https:// for a plain HTTP service. The public site works, but the setting should be checked before other services rely on it.
6. Trace the TLS entry in the Spring log. Spring once logged a TLS handshake on its plain HTTP port. The source was not traced. The public site was not affected.

Setup

Each step ends with a check. Do not start the next step until it passes. Tokens and identifiers are masked in every screenshot.

Assumptions

• The application runs on one Windows personal computer at home.
• The API is a Spring Boot application, and the page is a React application built with Vite.
• The domain is managed in Cloudflare, and no other service is exposed.

1. Pin the API to port 8090. Spring defaults to 8080, which other projects here already use. Two services on one port route requests to the wrong program with no error. The check is the startup log, which shows Tomcat on 8090.

   server:
     port: 8090

2. Configure Vite's preview server. The preview block fixes the host and port, fails on a port conflict, and lists the public hostname in allowedHosts. Without that entry, Vite returns 403 for the public address.

   preview: {
     host: "127.0.0.1",
     port: 4173,
     strictPort: true,
     allowedHosts: ["kanbanassist.vishnuvardhan.io"],
   },

   

3. Build and check locally. Run npm run build, then npm run preview. Open 127.0.0.1:4173 and send a chat message. If this fails, the problem is the app, not the tunnel.

   

4. Confirm Spring listens. In PowerShell, run Test-NetConnection 127.0.0.1 -Port 8090. The result must show TcpTestSucceeded : True. Command Prompt does not have this command.

   

5. Install the connector. Create the tunnel in the dashboard and copy the Windows command. Unblock the downloaded installer in its Properties dialog. Run the service command from an elevated prompt. The token in that command is a password. Keep it out of screenshots, repositories and chats.

   

   

   

6. Verify the connector, then add one route. The tunnel should show Healthy with no routes. Add one published route: subdomain kanbanassist, domain vishnuvardhan.io, service HTTP, URL 127.0.0.1:4173.

   

   

   

   

7. Test from outside. Open the public address on a device outside the home network and send a chat message. Testing from inside the house can hide problems a visitor would meet.

   

The frontend build

The React build produces static files: index.html, JavaScript and CSS. Any web server can host them, and no Node.js process runs at runtime. The API address is relative, so /api works on any host that serves both parts. A client-side route such as /board exists only in the browser, so the server must return index.html for it. Otherwise a direct visit returns a 404.

Healthy does not mean reachable

Each symptom points to one layer. Read the source of a message before searching its text, and run the checks in order.

What broke

Most failures were between components, not in the application.

The 403 that names its own fix

Visitors saw a 403 at the public address. Vite produced it, not Cloudflare or Spring, and the message named the setting to change: preview.allowedHosts. Identify which component produced an error before searching for its text.

The preview server that had stopped

The public chat failed, so the checks ran one hop at a time. Ping to the computer succeeded. The TCP test on 4173 failed. Port 8090 returned Spring's JSON 404 at the root, which showed Spring was running. The preview server had stopped. Restarting it fixed the problem.

The extra route

During testing I created a second route to the API hostname. It sent requests straight to Spring, bypassing Vite's host check and the /api rule. The masked row below is that route. I deleted it. Review the Routes table after every change.

A cause I did not prove

The chat stopped responding on the preview server. My first explanation, a missing proxy rule, was wrong. Vite already applies server.proxy when preview.proxy is not set. I then made the preview block explicit, and the chat works through the tunnel. I did not isolate which change fixed it, so I do not claim a cause.

Trade-offs

What it gives you. The router is untouched, and no inbound port is open. A changing home address does not break the site, because the connection is made outward. Cloudflare presents the certificate for the hostname, so nothing renews on the computer. Deleting the route stops public access at once. The setup used Cloudflare's free tier.

What it costs.

• TLS ends at the edge, so Cloudflare can read the requests and responses. Treat it like any hosted service.
• If the computer sleeps or the connector stops, the site is down. It has no failover.
• The token is a password. Anyone holding it can run a connector for the tunnel. Rotate it after any exposure.
• Routing lives in Cloudflare's dashboard. Moving to another provider later takes work.
• Cloudflare's terms restrict some heavy media on some plans. Read them before serving video or large downloads.

Takeaways

• The router already blocks unsolicited inbound traffic. Keep that protection.
• A Cloudflare Tunnel works because the computer opens the only connection, and it opens it outward.
• Test each option against the requirements. Here they ruled out port forwarding and cloud hosting.
• Serve the page and the API from one hostname. That avoids CORS and needs one route.
• A Healthy tunnel does not mean the app is running. Test the app on its own port, then through the tunnel.
• Every route is a public entry point. Review routes as carefully as firewall rules.

References

• Cloudflare Tunnel documentation: concepts and setup.
• Create a remote tunnel: the dashboard procedure.
• Tunnel routing: how hostnames map to services.
• Routing concepts: how routes are evaluated when more than one is configured.