Recommended Free Tools
You can publish a Coolify application through Cloudflare without forwarding router ports or exposing the server’s public IP. The working pattern is to run cloudflared on the server (or as a Coolify resource), create a Cloudflare Tunnel, and point a published hostname route at either Coolify’s proxy or the application’s host-mapped port. Visitors normally connect over HTTPS at Cloudflare’s edge; the tunnel-to-Coolify connection can remain HTTP unless your application requires TLS at the origin.
Antihost offers VPS plans with one-click Coolify, NVMe storage and a 14-day free trial.
What this setup does
A Cloudflare Tunnel creates an outbound connection from the machine running Coolify to Cloudflare. Public requests arrive at the hostname you publish, Cloudflare sends them through the tunnel, and cloudflared forwards them to a service reachable from the server. Because the connection is initiated outbound, you do not need to open an inbound router port or publish the origin server’s public IP.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThis is useful for a Coolify installation on a local server, including a Raspberry Pi, a home lab machine, or a virtual machine with internet access. It is also useful when several applications share one Coolify instance and you want Cloudflare to provide the public entry point for all of them.
The tunnel is not a replacement for deploying the application correctly. Coolify must be running, the target resource must be deployed, the connector must be able to reach the intended local service, and the hostname must match the tunnel route exactly.
#1 Best Overall
- Includes Raspberry Pi 5 with 2.4Ghz 64-bit quad-core CPU (8GB RAM)
- Includes 128GB Micro SD Card pre-loaded with 64-bit Raspberry Pi OS, USB MicroSD Card Reader
- CanaKit Turbine Black Case for the Raspberry Pi 5
- CanaKit Low Noise Bearing System Fan
- Mega Heat Sink - Black Anodized
Prerequisites
- A Cloudflare account.
- A domain managed by Cloudflare.
- A server or virtual machine with internet access where
cloudflaredcan run. - A working Coolify installation and a deployed target resource.
- Permission to create a tunnel, publish a hostname route, and manage DNS for the domain.
- Outbound firewall access for the connector. Restrictive firewalls may need an explicit allowance for Cloudflare’s tunnel traffic on port
7844.
Decide the tunnel’s scope before changing the application. Coolify documents an all-resources pattern for beginners and a single-resource pattern when only one application should be exposed.
Choose between all resources and one resource
| Pattern | Coolify configuration | Tunnel service target | Best fit |
|---|---|---|---|
| All resources | Deploy cloudflared in Coolify and route the tunnel to Coolify’s proxy. |
The local service endpoint used by the Coolify proxy. | Several applications, or a first setup where you want Coolify’s proxy to select the application by hostname. |
| Single resource | Remove the application’s existing public domains, set its exposed and mapped ports, then redeploy it. | The local address and host-mapped port that reaches that application; Coolify’s example uses http://localhost:4477. |
One isolated application with a deliberately narrow public route. |
When the all-resources pattern is simpler
With the all-resources design, Cloudflare sends requests to Coolify’s proxy. The proxy then uses the hostname and its own routing configuration to deliver each request to the matching deployed application. You create additional Cloudflare hostname routes as needed while keeping application-level routing in Coolify.
This avoids creating a separate tunnel service target for every application. It is usually the easier choice when you manage multiple projects, expect to add more projects, or do not want to redesign each application’s domain settings.
When a single-resource route is safer
A single-resource route limits the tunnel to one application. First remove that application’s existing public domains in Coolify. Then configure the resource’s exposed container port and mapped host port, deploy it, and publish the Cloudflare route to the mapped host port.
The documented http://localhost:4477 value is an illustration, not a universal Coolify port. Replace 4477 with the host port actually mapped on your server. A container-only port is not enough if cloudflared is forwarding to the host network.
Rank #2
- Includes Raspberry Pi 4 4GB Model B with 1.5GHz 64-bit quad-core CPU (4GB RAM)
- Includes Pre-Loaded 32GB EVO+ Micro SD Card (Class 10), USB MicroSD Card Reader
- CanaKit Premium High-Gloss Raspberry Pi 4 Case with Integrated Fan Mount, CanaKit Low Noise Bearing System Fan
- CanaKit 3.5A USB-C Raspberry Pi 4 Power Supply (US Plug) with Noise Filter, Set of Heat Sinks, Display Cable - 6 foot (Supports up to 4K60p)
- CanaKit USB-C PiSwitch (On/Off Power Switch for Raspberry Pi 4)
Prepare Coolify before creating the route
- Open Coolify and confirm the instance is online.
- Open the application or other resource you intend to publish and verify that it has completed deployment.
- Choose the all-resources or single-resource scope.
- For an all-resources tunnel, confirm that the Coolify proxy is running and that the connector will be able to reach its local endpoint.
- For a single-resource tunnel, remove the resource’s current public domains, set the exposed container port, set the host port mapping, save the configuration, and redeploy.
- Record the actual host-mapped port. This is the value that belongs in the Cloudflare Service URL, not merely the port declared inside the container.
Container port versus host-mapped port
Coolify can expose an application on one port inside its container and publish that service on a different port on the server. The tunnel connector needs the address and port that are reachable from the connector’s network context. If the host mapping is 4477, for example, the single-resource service target is http://localhost:4477 when that address is reachable from the connector on the same server.
Using the container-only port commonly produces a connection refusal or a 502 response even though the application appears healthy inside Coolify. Treat the host mapping as part of the tunnel configuration and update the route if you later change that mapping.
Create the Cloudflare Tunnel
- Sign in to Cloudflare and open Networking > Tunnels.
- Select Create Tunnel.
- Give the tunnel a name that identifies its Coolify server or purpose.
- Choose the operating system and architecture for the machine that will run
cloudflared. - Continue until Cloudflare displays the connector installation instructions and generated tunnel token.
- Copy the token into a secure password manager or deployment secret store. Do not place it in a public repository, a screenshot, a blog post, or an application log.
The tunnel exists in Cloudflare, but it will not become healthy until a connector authenticates with that token from the server running Coolify.
Run cloudflared with the tunnel token
Deploy it as a Coolify resource
- In Coolify, create or deploy the Cloudflared resource supplied for running the connector.
- Add the generated tunnel token as the resource’s environment variable, using the token field expected by the resource configuration.
- Deploy or restart the resource.
- Return to Cloudflare’s tunnel page and wait for the connector status to show a healthy, connected state.
Keep the token out of ordinary environment dumps and source control. Anyone who obtains it may be able to authenticate a connector to the tunnel, so treat it like a credential rather than ordinary configuration.
Install it directly on the server
You can instead install cloudflared on the Coolify host and start it with the token from Cloudflare’s connector instructions. This option is useful when you want the connector managed by the host operating system rather than by Coolify. The same requirements still apply: the process must remain running, it must have outbound internet access, and it must be able to reach the selected Coolify service.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesPublish a hostname route
- Open the tunnel’s Routes area in Cloudflare.
- Choose Add a published application route.
- Enter the subdomain and select the Cloudflare-managed domain that should receive traffic.
- Set Service URL to the local address and port that the connector can reach.
- Save the route, then repeat the process for any additional hostnames that should use the tunnel.
Service URL for all resources
For the all-resources pattern, the Service URL must point to Coolify’s proxy endpoint. Use the local proxy address exposed by your Coolify configuration rather than guessing an application container port. The proxy receives the hostname and forwards the request to the correct deployed resource.
Service URL for one resource
For the single-resource pattern, use the host-mapped port recorded during preparation. Coolify’s documented example is http://localhost:4477; substitute the port actually mapped on your server. The protocol in this basic pattern is HTTP between the connector and the local Coolify service.
If the connector runs in a separate container, verify that the chosen local address resolves from that connector’s network context. The important test is not whether the address works in a browser on another machine, but whether the cloudflared process can connect to it locally.
Configure DNS for the tunnel hostname
The hostname must resolve through Cloudflare’s tunnel target. Create or use a proxied DNS record for the published hostname that points to the tunnel’s cfargotunnel.com address, following Cloudflare’s documented record format.
Check the spelling of the subdomain, the selected zone, and the proxy status. A DNS record for a similar but different hostname does not satisfy the tunnel route, because Cloudflare matches the request hostname against the published route and ingress rules.
Rank #4
- Broadcom BCM2711, quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1. 5GHz
- 2. 4 GHz and 5. 0 GHz IEEE 802. 11b/g/n/ac wireless LAN, Bluetooth 5. 0, BLE
- 2 × USB 3. 0 ports, 2 x USB 2. 0 Ports
- 2 × micro HDMI ports supproting up to 4Kp60 video resolution
- Micro SD card slot for loading operating system and data storage
Finish ingress rules with a catch-all
If you manage the tunnel with a local configuration file, put a final catch-all ingress rule after the specific hostname rules:
service: http_status:404The catch-all must be last. It gives unmatched hostnames a deliberate 404 response instead of allowing them to fall through to an unintended service. When you add a new hostname rule, place it before this final rule.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Decide how TLS should work
Basic edge-HTTPS pattern
The basic Coolify pattern uses HTTPS from the visitor to Cloudflare and HTTP from the tunnel to the Coolify proxy or local application. This is often sufficient when the application is designed to terminate public HTTPS at Cloudflare and does not require encrypted traffic at the origin.
Do not infer that an HTTPS URL in the browser means the origin connection is also HTTPS. These are two separate connections with separate protocol and certificate settings.
Full TLS to the origin
If the application requires HTTPS at the origin for cookies, login behavior, secure redirects, or another protocol requirement, use Coolify’s full-TLS configuration. The origin certificate name must match the hostname and origin settings used by the tunnel. Changing the zone’s SSL mode by itself does not repair an origin hostname mismatch.
Best Value
- Includes Raspberry Pi 5 16GB with 2.4Ghz 64-bit quad-core CPU (16GB RAM)
- Includes 128GB Micro SD Card pre-loaded with 64-bit Raspberry Pi OS, USB MicroSD Card Reader
- CanaKit Turbine Black Case for the Raspberry Pi 5
- CanaKit Low Noise Bearing System Fan
- Mega Heat Sink - Black Anodized
Plan the certificate name, the origin protocol, and the Coolify proxy configuration together. A certificate that is valid for a different hostname can still produce a TLS or certificate error even when DNS and the tunnel connector are healthy.
Test the published hostname
- In Cloudflare, confirm that the tunnel and its connector report a healthy connection.
- Confirm that the published route shows the intended subdomain, domain, and Service URL.
- Open the exact hostname in a browser and verify that the expected Coolify application responds.
- Check the application logs in Coolify if the response is an application error.
- Check
cloudflaredlogs for connection failures, an unreachable service, an unexpected hostname, or an origin TLS error. - If you changed a port mapping, route, DNS record, or TLS setting, retest after the relevant resource has redeployed or the connector has reloaded its configuration.
A healthy tunnel only proves that Cloudflare can reach the connector. It does not prove that the Service URL reaches the correct application, that the hostname matches an ingress rule, or that the origin certificate is valid.
Troubleshoot 404, 502, TLS, and connection failures
| Symptom | Likely cause | What to check |
|---|---|---|
| 404 from the tunnel | The requested hostname does not match a specific ingress rule, or the rule order is wrong. | Compare the browser hostname with the route character for character. Ensure the final service: http_status:404 catch-all is present and appears after every specific rule. |
| 502 or connection refused | The Service URL uses a container-only port, the host mapping is wrong, or the local service is not running. | Verify the resource deployment, then change the Service URL to the host-mapped port reachable by cloudflared. The illustrative http://localhost:4477 value is valid only when 4477 is your actual mapping. |
| TLS or certificate mismatch | The tunnel’s origin protocol or certificate hostname does not match the Coolify origin configuration. | Use the full-TLS setup when origin HTTPS is required. Check the certificate name and origin hostname; do not rely on a zone SSL-mode change alone. |
| Tunnel will not connect | The connector cannot reach Cloudflare, the token is incomplete, or the token is not available to the process. | Confirm the complete token is stored in the connector environment, inspect the connector logs, and allow outbound Cloudflare tunnel traffic through port 7844 if the firewall is restrictive. |
| The route is healthy but the wrong application answers | The request is reaching Coolify’s proxy, but the hostname does not select the intended application. | For all resources, check the application’s Coolify domain configuration and the exact published hostname. For a single resource, verify that the route points directly to that resource’s mapped host port. |
Reading a 404 correctly
A tunnel-generated 404 usually indicates routing rather than application downtime. Start with the hostname and ingress rule order. If the request never matches a rule, changing the application’s container port will not fix it.
Reading a 502 correctly
A 502 or refused connection generally means that the connector reached the server but could not establish the next connection to the configured Service URL. Compare the route with the host mapping shown in Coolify and confirm that the target resource is deployed.
What changes for SSH or other non-HTTP traffic?
Published application routes are designed for HTTP-style hostname traffic. SSH and other TCP-based protocols require cloudflared on the client side as well as the server-side connector. The client-assisted connection is a different operating pattern from opening a browser to a public application hostname.
If your immediate goal is a web interface, keep the route focused on HTTP and solve the hostname, service port, and TLS settings first. Add non-HTTP access only after you have a clear client-side connection procedure and authentication plan.
Operational checklist
- Keep the Cloudflare tunnel token secret and rotate access if it is exposed.
- Use a separate published hostname for each application that needs independent routing.
- Record whether each route targets Coolify’s proxy or a particular host-mapped application port.
- Keep the catch-all ingress rule last when configuration is managed locally.
- Review both Cloudflare connector logs and Coolify application logs; they describe different halves of the request path.
- Remember that removing inbound router forwarding hides the origin from direct exposure but does not replace application authentication or authorization.
- When changing ports, domains, or certificates, update the corresponding tunnel route and test the exact public hostname again.
Which configuration should you use?
Choose the all-resources pattern if you are new to the setup, operate several Coolify applications, or want Coolify’s proxy to handle hostname-based routing. Choose the single-resource pattern if one application is the only thing that should be public and you are comfortable maintaining its host-port mapping.
In either case, the critical detail is the same: the Service URL must reach the correct local endpoint from the connector’s point of view. Once the connector is healthy, DNS is proxied to the tunnel, the hostname matches the route, and TLS settings agree on both sides, Coolify can serve the application publicly without router port forwarding.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
