Coolify hard to sett up behind cloudflare tunnel

[TheRoccoB]

I wanted a Coolify install that, itself, was behind a cloudflared tunnel. I got it working but it was very tricky—I needed to manually update a conf file to get rid of the port 8000 exposure that broke through my UFW rules.

I love Coolify but I absolutely hate that it does this port-8000-breaks-ufw thing and there’s no way to quickly turn that off in the UI. Seems like a major vulnerability to me.

Then I needed to add a bunch of other mappings to realtime services in Coolify. Would be nice to at least have a tutorial about how to set that up and perhaps I could contribute.

So I guess the feature request is twofold.

1. Easy way to turn off any mappings like 8000 that break through ufw.
2. Tutorial about what mappings are needed to get cool working behind a CF tunnel.

I could write a draft of number 2 for the docs site if you guys are interested.

[djsisson]

@TheRoccoB any ports mapped by docker, will still be available even using ufw

https://docs.docker.com/engine/network/packet-filtering-firewalls/#docker-and-ufw

to turn this off for coolify you add the following file
/data/coolify/source/docker-compose.custom.yml
with contents

services:
  coolify:
    ports: !reset []

as to what mappings, you do not need to use any other than localhost 80, just let the proxy handle all the routings

so for the tunnel you just need apex domain to HTTP localhost 80 and * (wildcard) to localhost 80

if you want to switch to HTTPS, you will need to add your origin domain certificate to your host as well as add the origin domain name to the TLS settings for each cf tunnel entry

you do not need to map any of the realtime entries

[TheRoccoB]

That ports lockdown thing should be an easy option in the UI if that's possible. Because I think a lot of people will just not care and keep it open.

Just put a big red warning in there to make sure you have another way of access set up. Or maybe don't even allow it if they're configuring from port 8000.

Here's an image of some of the tunnel mappings I had to set up to get this to work:

I might have needed to manually edit a few conf files to get things pointing in the right direction too.

I think this setup is very secure--something that's really important to me when I set up a service that has root access to all my "stuff". Would love it if this was easier, and perhaps, the recommended way to install coolify. Happy to collab / contribute a bit more on this.

Edit: sorry I didn't see that you already replied above. I'll play around with a fresh install and see what mappings I actually need to make.

[TheRoccoB]

OK, I reread your comment, it sounds like I need a proxy on the server itself. I guess that would be like nginx or whatever, is that right? Sorry to be n00b. I'll run your response through an LLM and see what it tells me.

[TheRoccoB]

OK... another thing I tried is pointing Cloudflare tunnel to localhost:80, which resolves (but to a 404). I don't understand exactly what you mean about wildcard and proxy, even after workshopping it with GPT :-).

One other thing I tried was in /settings, setting the "Instance's domain" to https://mysub.mydomain.com, and that, ironically stopped the 404's, but led to a too many redirects error. It's trying to reload itself over and over in devtools.

[TheRoccoB]

OK, I finally got it working.

The key: point tunnel to localhost:80, in the coolify UI, set the instance domain to http://coolify.mydomain.com.

The key to the too many redirects error was to set the coolify instance domain to http://coolify.mydomain.com (note: not https) and let cloudflare handle the SSL. It correctly redirected me to https in the browser.

Still I wonder if there's something that could be done to make coolify "just work" without the too many redirects. Saw another post about this.

I'll paste the wordy Gemini response about why this might have worked after this post.

[TheRoccoB]

From Gemini:

It's excellent that setting Coolify's FQDN (Fully Qualified Domain Name) to http://coolify.yourcoolsite.com resolved the "Too Many Redirects" error, while still ensuring you get a secure HTTPS connection in your browser!

Here's a breakdown of why this specific configuration likely worked:

Coolify's Internal Proxy Behavior:

When you configured Coolify's FQDN setting as http://coolify.yourcoolsite.com, you effectively told its internal reverse proxy (often Traefik, which Coolify uses) that the expected internal scheme for the Coolify application itself, from the proxy's viewpoint, is HTTP.
This likely prevented Coolify's own proxy from automatically initiating an HTTP-to-HTTPS redirect for coolify.yourcoolsite.com. As discussed in the GitHub thread, setting the domain with https:// in Coolify sometimes causes its proxy to enforce an HTTPS redirect, potentially even if a separate "Force HTTPS" option within Coolify is turned off. By specifying http:// in the FQDN, you've indicated to Coolify's proxy that it doesn't need to perform this redirect itself.
Cloudflare's Role (SSL/TLS Mode: "Full"):

Your Cloudflare SSL/TLS encryption mode is set to "Full" (as seen in your screenshot). This means:
Your web browser connects to Cloudflare's edge servers securely over HTTPS when you access https://coolify.yourcoolsite.com.
Cloudflare then connects to your origin server (where Coolify is running, via your Cloudflare Tunnel) using the protocol specified in your tunnel's service configuration. Let's assume, for this explanation, that your Cloudflare Tunnel service is set to connect to http://localhost:80 on your server.
Critically, even if the final hop from the Cloudflare Tunnel to your Coolify instance is HTTP, Cloudflare adds important headers to the request. The most relevant one here is X-Forwarded-Proto: https. This header informs your Coolify instance that the original connection from the visitor's browser to Cloudflare was secure (HTTPS). This was a key piece of information in the GitHub thread for applications to correctly identify the original scheme.

Why You Still Get HTTPS in the Browser:

The fact that your browser ultimately loads https://coolify.yourcoolsite.com (even if you hypothetically typed http://coolify.yourcoolsite.com) is typically due to Cloudflare's settings.
You might have the "Always Use HTTPS" feature enabled in your Cloudflare dashboard (under SSL/TLS > Edge Certificates). If active, Cloudflare automatically redirects any HTTP requests for your site to HTTPS at its edge servers, before the request even reaches your origin server. This is generally a good practice. The GitHub thread did suggest disabling this ("Always Use HTTPS") as a troubleshooting step if redirect loops occur. If it's off, typing http:// might initially reach your server as HTTP (via the tunnel), but then Coolify, seeing X-Forwarded-Proto: https, should generate all its internal links and asset URLs with https://.
If "Always Use HTTPS" is off, but you directly type or click a link for https://coolify.yourcoolsite.com, it works because Cloudflare handles the HTTPS, then communicates with your origin as configured (e.g., via the tunnel to http://localhost:80), passing along the X-Forwarded-Proto: https header.
In summary, the "Too Many Redirects" loop was likely occurring because both Cloudflare and Coolify were attempting to manage the HTTP-to-HTTPS redirection, leading to a conflict:

Previous State (Coolify FQDN likely set to https://coolify.yourcoolsite.com):

Browser initiates an HTTPS request to Cloudflare.
Cloudflare (with SSL mode "Full"), via the tunnel, makes an HTTP request (but includes X-Forwarded-Proto: https) to your Coolify server.
Coolify's proxy, having its FQDN configured as https://..., might have seen the incoming HTTP request (from the tunnel) and, either by not fully processing X-Forwarded-Proto for its redirect logic or due to its own redirect rules, initiated its own 302 redirect back to https://coolify.yourcoolsite.com. This redirect would go back through Cloudflare to the browser, creating the loop.
Current Working State (Coolify FQDN set to http://coolify.yourcoolsite.com):

Browser initiates an HTTPS request to Cloudflare (or an HTTP request that Cloudflare then upgrades to HTTPS if "Always Use HTTPS" is enabled [though the thread suggested disabling this for troubleshooting] ).
Cloudflare (SSL mode "Full"), via the tunnel, makes an HTTP request (including X-Forwarded-Proto: https) to your Coolify server.
Coolify's proxy, now configured with an http:// FQDN, is content to serve requests over HTTP internally. It receives the X-Forwarded-Proto: https header, which is crucial for it to generate correct absolute URLs (for its own assets, internal links, etc.) using the https:// scheme, ensuring the user experience remains secure. However, it no longer triggers its own HTTP-to-HTTPS redirect because its defined "target" scheme from its own FQDN setting is HTTP.
This configuration effectively delegates the primary HTTPS enforcement and SSL certificate management to Cloudflare at the edge. Coolify then operates correctly behind this setup, understanding that the original user connection was secure, without introducing a conflicting redirect. This approach is consistent with the troubleshooting experiences shared in the GitHub thread, where controlling the application's own SSL/redirect mechanisms is vital when placed behind another reverse proxy like Cloudflare.

[djsisson]

All of your issues are covered in the docs already

https://coolify.io/docs/knowledge-base/cloudflare/tunnels/all-resource#_3-setup-cloudflare-tunnel-on-coolify

[TheRoccoB]

Thank you. I see specifically that I missed when I read that doc the first time:

HEADS UP!

You should enter the domain as HTTP because Cloudflare handles HTTPS and TLS terminations. If you use HTTPS for your resource, you may encounter a TOO_MANY_REDIRECTS error.

If your app requires HTTPS for features like cookies or login, follow the [Full TLS HTTPS Guide ↗](https://coolify.io/docs/knowledge-base/cloudflare/tunnels/full-tls) after completing this guide.

Nice to see confirmation of this problem in the official though!

I'm basically building an interactive terminal bash script to help people set up cloudflared in front of coolify, and I want to get everything as close to perfect as possible.

This setup took me quite a lot of time to get right, even with the doc that you shared.

[TheRoccoB]

Also last question... after I add the yaml file to update /data/coolify/source/docker-compose.custom.yml is there a better / faster way to get this to take than running the wget install script from github? Ilike is there something in /data/coolify that will allow me to restart the services? I see a script in there called upgrade.sh, would that be better?

[TheRoccoB]

created pr to improve firewall docs, LMK what you think coollabsio/coolify-docs#292