You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i'm running Coolify v4.0.0-beta.379 and when deploying the GitLab service with no extra configurations, the server just returns Bad Gateway to every single request made to it. I've been hosting it as a docker image instead of as a service since then and today a few hours ago I realized I couldn't set the external_url config because it made the instance go back to the Bad Gateway error I was initially having. After loads of investigating, I found out that GitLab with it's default Coolify settings fails to create and/or set the SSL certificate if you set the external_url to start with https:// instead of http://. This is solvable by setting the following to the config file (/etc/gitlab/gitlab.rb, I'm using a file storage since I'm running it from its Docker image):
What this does is to tell GitLab that it's running on https, but to listen for HTTP instead since it's behind Coolify's reverse proxy which already has automatic SSL setup. This immediately fixed the issue. AFAIK there's more than one Nginx config, e.g. for GitLab Pages, which will also cause the same problem. This can also be fixed doing the same above but for the pages Nginx config. I.e.
pages_external_url'https://your-pages-domain.dev'# `gitlab_pages['enable'] = true` shouldn't be here since it's default is set to false, but I believe the rest of the configurations should be set by default since they'll otherwise cause the service to immediately crash.pages_nginx['listen_https']=falsepages_nginx['listen_port']=80
I know GitLab runs other Nginx services too, so this should be repeated for the rest of the GitLab services. (Unintuitively IMO) setting the external_url or similar settings to https:// FQDN implicitly enables HTTPS which causes the service to crash.
Steps to Reproduce
Create a new GitLab service
Set the FQDN to an HTTPS URL
Deploy the service
Make any request to the GitLab URL
Example Repository URL
No response
Coolify Version
v4.0.0-beta.379
Are you using Coolify Cloud?
No (self-hosted)
Operating System and Version (self-hosted)
Ubuntu 24.04
Additional Information
No response
The text was updated successfully, but these errors were encountered:
Nekidev
added
🐛 Bug
Reported issues that need to be reproduced by the team.
🔍 Triage
Issues that need assessment and prioritization.
labels
Dec 25, 2024
Error Message and Logs
i'm running Coolify
v4.0.0-beta.379
and when deploying the GitLab service with no extra configurations, the server just returns Bad Gateway to every single request made to it. I've been hosting it as a docker image instead of as a service since then and today a few hours ago I realized I couldn't set theexternal_url
config because it made the instance go back to the Bad Gateway error I was initially having. After loads of investigating, I found out that GitLab with it's default Coolify settings fails to create and/or set the SSL certificate if you set theexternal_url
to start withhttps://
instead ofhttp://
. This is solvable by setting the following to the config file (/etc/gitlab/gitlab.rb
, I'm using a file storage since I'm running it from its Docker image):What this does is to tell GitLab that it's running on https, but to listen for HTTP instead since it's behind Coolify's reverse proxy which already has automatic SSL setup. This immediately fixed the issue. AFAIK there's more than one Nginx config, e.g. for GitLab Pages, which will also cause the same problem. This can also be fixed doing the same above but for the pages Nginx config. I.e.
I know GitLab runs other Nginx services too, so this should be repeated for the rest of the GitLab services. (Unintuitively IMO) setting the
external_url
or similar settings tohttps://
FQDN implicitly enables HTTPS which causes the service to crash.Steps to Reproduce
Example Repository URL
No response
Coolify Version
v4.0.0-beta.379
Are you using Coolify Cloud?
No (self-hosted)
Operating System and Version (self-hosted)
Ubuntu 24.04
Additional Information
No response
The text was updated successfully, but these errors were encountered: