[Bug]: checkmate don't work with cloudflare

[louanfontenele]

Error Message and Logs

Client: client.txt MongoDB: mongodb.txt Redis: redis.txt Server: server.txt

Steps to Reproduce

1. Use clouflare
2. Install checkmate
3. Try to create an account
4. Can't login

Example Repository URL

No response

Coolify Version

Coolify v4.0.0-beta.379

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

Ubuntu 24.04

Additional Information

Hello everyone, how are you? I'm having problems installing checkmate. It installs correctly, but says it's unhealthy.

[louanfontenele]

@ShadowArcanist found this:

[gorkem-bwl]

Let's check this on our end (Checkmate) - thank you @louanfontenele

[louanfontenele]

Let's check this on our end (Checkmate) - thank you @louanfontenele

I really don't know if the problem is Cloudflare, but another user said that he doesn't use Cloudflare and was able to connect, all other applications work, but this one doesn't work correctly.

[TPGLLC-US]

i am having a similar issue. No console output. The login button just shows a spinner and hangs on the login screen Coolify Cloud I was not able to use the Coolify template for the checkmate resource because when I click it the resource templates page just reloads and does not proceed.

[louanfontenele]

i am having a similar issue. No console output. The login button just shows a spinner and hangs on the login screen Coolify Cloud I was not able to use the Coolify template for the checkmate resource because when I click it the resource templates page just reloads and does not proceed.

The same app? Checkmate?

[TPGLLC-US]

Yes checkmate. See Docker Compose below

version: '3.8'
services:
  client:
    image: 'bluewaveuptime/uptime_client:latest'
    environment:
      UPTIME_APP_API_BASE_URL: 'https://myServerURL.dev:5000/api/v1'
    ports:
      - '80:80'
      - '443:443'
    depends_on:
      - server
    restart: always
  server:
    image: 'bluewaveuptime/uptime_server:latest'
    ports:
      - '5000:5000'
    depends_on:
      - redis
      - mongodb
    environment:
      - 'DB_CONNECTION_STRING=mongodb://mongodb:27017/uptime_db'
      - REDIS_HOST=redis
  redis:
    image: 'bluewaveuptime/uptime_redis:latest'
    ports:
      - '6379:6379'
    volumes:
      - './redis/data:/data'
  mongodb:
    image: 'bluewaveuptime/uptime_database_mongo:latest'
    volumes:
      - './mongo/data:/data/db'
    command:
      - mongod
      - '--quiet'
    ports:
      - '27017:27017'

[louanfontenele]

Yes checkmate. See Docker Compose below

version: '3.8'
services:
  client:
    image: 'bluewaveuptime/uptime_client:latest'
    environment:
      UPTIME_APP_API_BASE_URL: 'https://myServerURL.dev:5000/api/v1'
    ports:
      - '80:80'
      - '443:443'
    depends_on:
      - server
    restart: always
  server:
    image: 'bluewaveuptime/uptime_server:latest'
    ports:
      - '5000:5000'
    depends_on:
      - redis
      - mongodb
    environment:
      - 'DB_CONNECTION_STRING=mongodb://mongodb:27017/uptime_db'
      - REDIS_HOST=redis
  redis:
    image: 'bluewaveuptime/uptime_redis:latest'
    ports:
      - '6379:6379'
    volumes:
      - './redis/data:/data'
  mongodb:
    image: 'bluewaveuptime/uptime_database_mongo:latest'
    volumes:
      - './mongo/data:/data/db'
    command:
      - mongod
      - '--quiet'
    ports:
      - '27017:27017'

Mine docker compose:

services:
  client:
    image: 'bluewaveuptime/uptime_client:latest'
    environment:
      - SERVICE_FQDN_CHECKMATE_80
      - 'UPTIME_APP_API_BASE_URL=${SERVICE_FQDN_CHECKMATESERVER_5000}/api/v1'
    depends_on:
      - server
  server:
    image: 'bluewaveuptime/uptime_server:latest'
    environment:
      - SERVICE_FQDN_CHECKMATESERVER_5000
      - 'JWT_SECRET=${SERVICE_PASSWORD_64_JWT}'
      - 'REFRESH_TOKEN_SECRET=${SERVICE_PASSWORD_64_REFRESH}'
      - 'SYSTEM_EMAIL_ADDRESS=${SYSTEM_EMAIL_ADDRESS:[email protected]}'
      - 'SYSTEM_EMAIL_PASSWORD=${SERVICE_PASSWORD_64_EMAIL}'
      - 'SYSTEM_EMAIL_HOST=${SYSTEM_EMAIL_HOST}'
      - 'SYSTEM_EMAIL_PORT=${SYSTEM_EMAIL_PORT}'
      - 'PAGESPEED_API_KEY=${PAGESPEED_API_KEY}'
      - 'DB_CONNECTION_STRING=${DB_CONNECTION_STRING:-mongodb://mongodb:27017/uptime_db}'
      - 'REDIS_HOST=${REDIS_HOST:-redis}'
      - 'REDIS_PORT=${REDIS_PORT:-6379}'
      - 'DB_TYPE=${DB_TYPE:-MongoDB}'
      - 'TOKEN_TTL=${TOKEN_TTL:-99d}'
      - 'REFRESH_TOKEN_TTL=${REFRESH_TOKEN_TTL:-99d}'
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
    depends_on:
      - redis
      - mongodb
  redis:
    image: 'bluewaveuptime/uptime_redis:latest'
    volumes:
      - 'redis:/data'
  mongodb:
    image: 'bluewaveuptime/uptime_database_mongo:latest'
    volumes:
      - 'mongodb:/data/db'
    command:
      - mongod
      - '--quiet'

[gorkem-bwl]

i am having a similar issue. No console output. The login button just shows a spinner and hangs on the login screen Coolify Cloud I was not able to use the Coolify template for the checkmate resource because when I click it the resource templates page just reloads and does not proceed.

Do you also use Cloudflare Tunnels?

[Sh3nron]

I was not able to use the Coolify template for the checkmate resource because when I click it the resource templates page just reloads and does not proceed.

I am having the same problem on coolify cloud.

[gorkem-bwl]

I was not able to use the Coolify template for the checkmate resource because when I click it the resource templates page just reloads and does not proceed.

I am having the same problem on coolify cloud.

Do you use CloudFlare Tunnels as well? @Sh3nron

[louanfontenele]

Well, I believe I discovered the problem, the issue is that I cannot edit the variables in the first image, even editing the links through the Coolify settings, due to the inconsistency, and therefore, it cannot connect, however when I leave the original link, it works normally.

[louanfontenele]

Even though I managed to edit the variables, the error still occurs, but if I leave everything normal, including the extended URLs, it works normally.

But that's it, I disabled Cloudflare, created one from scratch, editing the domains, but it didn't work.

When used normally (with that generated and extended domain), it was able to connect without any problems.

[Sh3nron]

I was not able to use the Coolify template for the checkmate resource because when I click it the resource templates page just reloads and does not proceed.

I am having the same problem on coolify cloud.

Do you use CloudFlare Tunnels as well? @Sh3nron

I do not however the domain is registered on cloudflare and they are providing a proxy. The issue appears to be related to the template having a bug. See @louanfontenele screenshot above.

[github-actions[bot]]

This issue will be automatically closed in a few days if no response is received. Please provide an update with the requested information.

[louanfontenele]

Any news?

[biewdev]

same bug here

[gorkem-bwl]

same bug here

Thanks for confirming. One of our devs (Checkmate) are working on it now.

[miq-codes]

This is working fine for me.

Created three public hostname in cloudflare tunnel.

c-client.mydomain.com -> pointing to http://localhost:5800 c-api.mydomain.com -> pointing to http://localhost:5000 c-agent.mydomain.com -> pointing to http://localhost:59232

My docker-compose

services:
  client:
    image: bluewaveuptime/uptime_client:latest
    restart: always
    environment:
      UPTIME_APP_API_BASE_URL: "https://c-api.mydomain.com/api/v1"
    ports:
      - "5800:80"
      - "5443:443"
    depends_on:
      - server
  server:
    image: bluewaveuptime/uptime_server:latest
    restart: always
    ports:
      - "5000:5000"
    depends_on:
      - redis
      - mongodb
    environment:
      - DB_CONNECTION_STRING=mongodb://mongodb:27017/uptime_db
      - REDIS_HOST=redis
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
  redis:
    image: bluewaveuptime/uptime_redis:latest
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis/data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 5s
  mongodb:
    image: bluewaveuptime/uptime_database_mongo:latest
    restart: always
    volumes:
      - ./mongo/data:/data/db
    command: ["mongod", "--quiet"]
    ports:
      - "27017:27017"
  capture:
    image: ghcr.io/bluewave-labs/capture:latest
    restart: always
    ports:
      - "59232:59232"
    volumes:
      - /etc/os-release:/etc/os-release:ro
    environment:
      - API_SECRET=MY_API_SECRET

[gorkem-bwl]

We had a look at it and we think that env variables might have been set with double quotes, which shouldn't be the case. That's something we figured out users may have an issue.

[LemDog]

Just providing this image seen from trying to get this to work as well.

Also using cloud-flare tunnel. There is a particular API call made that is using some unmodifiable value. I tried everything I could think of from the Coolify dashboard but no dice. Works perfectly if I don't touch anything and leave it with the autogenerated FQDNs.

Tried: Recreating env variables with proper FQDNs before deploying. Use hard-coded static values within the docker compose for fields where FQDN is present.

[ajhollid]

Hi @LemDog ,

When you mentioned

There is a particular API call made that is using some unmodifiable value

do you mean all of the other API calls are working as expected?

There aren't any hardcoded values for API calls, they all use the same base API url that is specified in the env vars 🤔

Can you share what env vars you have set up?

[onigunn]

I've tried to set checkmate up with my own hetzner hosted coolify instance and it seems like on adding the service the slipp.io domains are hardcoded. So after creating, changing domains just pointing to the initial sslip.io domains. Env vars cannot be edited either (greyed out).

Is this related?

[gorkem-bwl]

@onigunn can you give me more context about sslip.io domain? Is this related to Checkmate?

[onigunn]

@gorkem-bwl If you create a new checkmate instance from the coolify instance, the sslip.io domain is prefilled in the configuration. This prefilled domain can be edited in the coolify UI but will not have an effect to the checkmate instance. The checkmate env vars are still pointing to the sslip.io domains. And that is - atleast for me - causing the same issue as mentioned in the origin bug report. FE reports network error - as it tries to connect to the sslip.io domains.

I would say its related to the checkmate coolify template.

I'm running on v4.0.0-beta.407.

[ycsh-w]

@gorkem-bwl If you create a new checkmate instance from the coolify instance, the sslip.io domain is prefilled in the configuration. This prefilled domain can be edited in the coolify UI but will not have an effect to the checkmate instance. The checkmate env vars are still pointing to the sslip.io domains. And that is - atleast for me - causing the same issue as mentioned in the origin bug report. FE reports network error - as it tries to connect to the sslip.io domains.

I would say its related to the checkmate coolify template.

I'm running on v4.0.0-beta.407.

Yes I think something is indeed hardcoded because it does not change no matter how I change the env vars. Giving me CORS problem

[ycsh-w]

Hi @LemDog ,

When you mentioned

There is a particular API call made that is using some unmodifiable value

do you mean all of the other API calls are working as expected?

There aren't any hardcoded values for API calls, they all use the same base API url that is specified in the env vars 🤔

Can you share what env vars you have set up?

What we mean here is that there is something wrong with the base URL all API calls get to.

https://github.com/coollabsio/coolify/blob/4a1f8e925f6c6d24987b40d2d30186f35803e40f/templates/compose/checkmate.yaml#L12

We are having trouble having this value modified and reflected in our deployment. It seems like, this value sticks to a certain one, and no matter what we did to change SERVICE_FQDN_CHECKMATESERVER_5000 or just hardcode this value in the docker compose file, at the end of the day the base URL our deployment gets is still the original one without modification.

I am not sure if it's a checkmate problem, Coolify problem or Cloudflare problem. To me it's least likely Cloudflare and most likely Coolify.

[biewdev]

Hi @LemDog , When you mentioned

There is a particular API call made that is using some unmodifiable value

do you mean all of the other API calls are working as expected? There aren't any hardcoded values for API calls, they all use the same base API url that is specified in the env vars 🤔 Can you share what env vars you have set up?

What we mean here is that there is something wrong with the base URL all API calls get to.

coolify/templates/compose/checkmate.yaml

Line 12 in 4a1f8e9

• UPTIME_APP_API_BASE_URL=${SERVICE_FQDN_CHECKMATESERVER_5000}/api/v1 We are having trouble having this value modified and reflected in our deployment. It seems like, this value sticks to a certain one, and no matter what we did to change SERVICE_FQDN_CHECKMATESERVER_5000 or just hardcode this value in the docker compose file, at the end of the day the base URL our deployment gets is still the original one without modification.

I am not sure if it's a checkmate problem, Coolify problem or Cloudflare problem. To me it's least likely Cloudflare and most likely Coolify.

That's exactly what's happening to me too. I've tried everything, but no success either. I believe it's an issue with Checkmate, because other services work correctly when I change the URL.

[includenull]

I was also having the same issue using the checkmate template.

The frontend was insisting on trying to connect to the api using the generated domain even though I set a new domain.

The issue for me was a combination of docker compose config and Cloudflare cache.

1. Docker Compose. If you change the domain, you need to change the docker compose too. 'UPTIME_APP_API_BASE_URL=${SERVICE_FQDN_CHECKMATESERVER_5000}/api/v1' will generate the domain here, so you need to change this line to match your new URL. e.g. 'UPTIME_APP_API_BASE_URL=https://your-new-url.domain.com/api/v1'

2. The client doesn't seem to have any cache busting so the React app gets built with the same filenames each time, even if environment variables have changed. In my case, index-CO2SgZMe.js was being cached in Cloudflare with the wrong API url in the code.
   I cleared the file from CloudFlare cache and it's working.

[kevin9092]

@includenull I think there is something wrong with the docker setup provided by Checkmate for the Coolify service.

Spin up a fresh Checkmate service in Coolify and you will notice:

• Default settings work on a fresh start, however restarting the service will randomly break the server with a CORS issue on the client side. Example: Access to XMLHttpRequest at 'https://checkmateserver-ds8084o8k4cgggckos8o8wgo.domain.com/api/v1/auth/login' from origin 'https://checkmate-ds8084o8k4cgggckos8o8wgo.domain.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

• Changing domain does not work as intended and you need to manually edit the docker config file to fix this, but you will be hit with the same CORS issue above.

• Redis is spamming server logs with ReplyError: NOAUTH Authentication required. even though auth should not be required?

I did the same thing that you posted yesterday evening and it worked until I restarted my service and I got the CORS issue above, which is why I wanted to see if the same thing would happen with defaults and it did. This is an application set up issue, not a docker issue, as for some reason after a restart the application is no longer configured as a CORS allowed origin.

I may try to set this up manually instead of via the service later and report back.

[dropalltables]

This exact problem is happening to me too, fresh install with custom domains fails outright, with the exact same errors as everyone else. (Insecure Endpoint)