[Feature request] Allow for SECURE_CONNECTION override for some reverse proxy situation.

[LuckyPed]

Idea

Please allow for a way for us to disable SECURE_CONNECTION while using password.

Add a new env called something like "SECURE_REVERSE_PROXY" and only when this value is set to 1 then it will allow override of the condition that does not allow running the service with SECURE_CONNECTION being disable and password protection active.

This way, we have both the protection and warning to not allow people to run password unprotected, yet allow for people who are stuck with some reverse proxy problem like me.

My situation yesterday:

I'm using Coolify Panel and there was a easy 1 click install of this project which I liked a lot and worked instantly, until I restarted with new env to make it secure and have password protection, then it stop correctly linking to my address and would not open, after wasting some times I realize it's because Coolify using Traefik which do the securing process itself and send us to http, but the SECURE_CONNECTION force http, so it having mismatch problem.

I spend like 2 hours trying try different combinations or solutions, but the only working combination is to disable SECURE_CONNECTION but when I do that, I can't run password protection or the service won't be allowed to run.

There was a solution of adding label to the composer file but it would not work when I added it to the compose file for this docker, It's possible I have to add it to compose file for the traefik itself, but that would mean editing the traefik setting and restarting it which I never did since I started using coolify and I already run some production site on this host with thousands of users. So I don't want to risk it.

In the end I simply gave up after hours of wasted time and went to sleep.

All of this could have been solved by a simple option to override that forced SECURE_CONNECTION to be enabled and I would have a working firefox in only 10min.

I searched through the issues, there is multiple people with problem like me, not only on traefik but seems to be on some other reverse proxy as well, so I believe this feature will help many.

Thanks.

[jlesage]

Thanks for the suggestion and for clarifying your situation.

While the use case is understandable, I don’t think allowing insecure communication for services that require security is a good idea. The project philosophy is to encourage correct security patterns rather than provide escape hatches.

My main concern is avoiding configurations that are inherently unsafe or misleading, even when explicitly opt-in. Enabling authentication without transport security creates a situation where credentials and session data are transmitted in clear text over the (internal) network.

Most reverse proxies support forwarding traffic to an HTTPS backend service without issue. This is generally straightforward to configure in NGINX, Caddy, HAProxy, and similar proxies. I agree that Traefik, in particular, is more cumbersome to configure in this scenario. It does require updating the Traefik configuration, because this setup can’t be achieved with labels on the backend service alone. However, Traefik’s complexity here is not something I want to compensate for by weakening the container’s internal security model.

There is also a maintenance and support aspect. Once an “unsafe but allowed” mode exists, it inevitably becomes a source of bug reports and security questions. It becomes difficult to distinguish between genuine issues and side effects of intentionally weakened configurations. This is especially true since other features of the container depend on having a secure connection and won’t work otherwise. Keeping the container opinionated and secure-by-design helps reduce this long-term burden.

[LuckyPed]

Okay I understand.
I guess I look into making my own password protection on the page if possible or look for other alternatives.
Thanks.