Coolify behind another reverse proxy

[aleee-idk]

Hello!

I strugle for a couples of days for how to setup coolify behind another reverse proxy (Caddy in my case) without having duplicate certificates. For applications this wasn't a problem since I can control the traefik labels attached to the docker compose, but for services those labels are generated automatically and it adds the https routes and certresolver.

I knew the solutions couldn't be to complicated since coolify allows a lot of control over the proxy but the auto-generated labels gave me a lot of headache.

The solution in the end was to setup the domain of the service with HTTP (no HTTPS), with this simple action, the auto-generated TLS labels aren't included.

In retrospective it was pretty obvious but easily overlooked, I would suggest to add in the documentation or in the info popup this this behavior.

Here is my config in case somebody else is having a hard time:

Service example:

Treafik docker-compose.yml

version: '3.8'
networks:
  coolify:
    external: true
services:
  traefik:
    container_name: coolify-proxy
    image: 'traefik:v2.11'
    restart: unless-stopped
    extra_hosts:
      - 'host.docker.internal:host-gateway'
    networks:
      - coolify
    ports:
      - '80:80'
      - '443:443'
      - '8080:8080'
    healthcheck:
      test: 'wget -qO- http://localhost:80/ping || exit 1'
      interval: 4s
      timeout: 2s
      retries: 5
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock:ro'
      - '/data/coolify/proxy:/traefik'
    # environment:
      # - 'CF_DNS_API_TOKEN=super-secret-token'
    command:
      - '--ping=true'
      - '--ping.entrypoint=http'
      - '--api.dashboard=true'
      - '--api.insecure=true'
      - '--entrypoints.http.address=:80'
      - '--entryPoints.http.forwardedHeaders.trustedIPs=10.0.10.10'
      - '--entrypoints.https.address=:443'
      - '--entryPoints.https.forwardedHeaders.trustedIPs=10.0.10.10'
      - '--entrypoints.http.http.encodequerysemicolons=true'
      - '--entryPoints.http.http2.maxConcurrentStreams=50'
      - '--entrypoints.https.http.encodequerysemicolons=true'
      - '--entryPoints.https.http2.maxConcurrentStreams=50'
      - '--providers.docker.exposedbydefault=false'
      - '--providers.file.directory=/traefik/dynamic/'
      - '--providers.file.watch=true'
      # - '--certificatesresolvers.letsencrypt.acme.httpchallenge=true'
      # - '--certificatesresolvers.letsencrypt.acme.storage=/traefik/acme.json'
      # - '--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=http'
      # - '--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=cloudflare'
      # - '--certificatesresolvers.letsencrypt.acme.dnschallenge.delaybeforecheck=0'
      - '--providers.docker=true'
    labels:
      - traefik.enable=true
      - traefik.http.routers.traefik.entrypoints=http
      - traefik.http.routers.traefik.service=api@internal
      - traefik.http.services.traefik.loadbalancer.server.port=8080
      # - traefik.http.routers.traefik.tls.certresolver=letsencrypt
      # - traefik.http.routers.traefik.tls.domains[0].main=example.com
      # - traefik.http.routers.traefik.tls.domains[0].sans=*.example.com
      - coolify.managed=true

[vinicius507]

[aleee-idk]

Yeah, as I said:

The solution in the end was to setup the domain of the service with HTTP (no HTTPS), with this simple action, the auto-generated TLS labels aren't included.

Check the example I posted.

[mrn]

Thanks for this. Where is your docker-compose.yml for Traefik? Did you create it in /data/coolify/proxy?

[aleee-idk]

Yes, is in the default location where coolify creates it. You can update the config editing the file directly or via the WebApp in Servers > Localhost > Proxy

[peteryusuf]

Thanks for this post as it saved me a lot of headache.

[gltched-usr]

@aleee-idk Does this also work with nginx proxy manager?

And if so, can you guide me on how to correctly set it up?
Since nginx pm already uses port 80 and 443 we cant expose them under ports, correct?

[aleee-idk]

I had never used nginx proxy manager myself, but this should be able to work in any proxy you put on front of coolify since all of them solve the same problem.

On the proxy side, what you need to do is create a new rule that redirects to the HTTP port coolify is listening on, which by default is 80. Note that is the HTTP port, not the HTTPS (443 by default). This is like adding a new rule for a service that doesn't have HTTPS enabled.

On the coolify side, what you need to do is what I have explained above, that is: not using the "https" protocol in the definition of the service url, instead use only "http". I also commented out some labels in the proxy configuration, check out the code I posted.

[douglasg14b]

There seems to be a lot of "magic" happening behind the scenes that causes restrictions and confusion when straying off the intended path 🤔

Using http instead of https in the coolify config means that a reverse proxy to port 80 will result in the site being unusable since coolfy will try and load insecure resources despite being accessed as a secure site from the reverse proxy which is doing the TLS termination.... Which most browsers block these days.

And if you try and revere proxy to the 443 port, it just doesn't work at all, coolify returns a 404 page.

I can only get it to work by revere proxying to port 8000, however this completely kills the terminal and a bunch of other features.