[Enhancement]: Improved domain configuration for allowing "www to non-www" / "non-www to www "redirects

[keichinger]

Request Type

Improvement

Description

Hi,

Backstory

yesterday, I was setting up a new server for me to play with. Properly setting up Coolify and actually using it was on my personal bucket list. Moving off from a regularly installed Caddy and PHP to everything being managed by Coolify was one of the goals.

After messing around for a while with a Docker Compose setup for my Caddy + PHP8.4, to more or less expose a static directory on my server for me to upload files to went as expected. The docs themselves were for my taste a bit too vague and assumed too much deeper knowledge for a few topics, but that's a different thing.

One thing I was kind of baffled by was how utterly cumbersome fragile it was to setup something, that is usually automagically done in a webserver like Caddy, or only a handful of lines in Nginx: Automatic redirects for "www to non-www" / "non-www to www".

After searching through the Coolify backend for a while, reading through all the (kind-of limited) docs on Traefik, as this was configured as my default proxy, I learned that it also handles Let's Encrypt certificates, but doesn't have a fancy option to handle the redirects. It does a lot of things, but doesn't come with something as integral and fundamental, that most likely 99% of all actual web apps need, and shouldn't need to implement in app code itself.

I found the docs on how to set up the redirects (https://coolify.io/docs/knowledge-base/proxy/traefik/redirects#www-non-www), but honestly, it's a bit wild and cumbersome.

For every web app I'd wanted to host within Coolify that exposes itself to the web, I'd need to go into the docker-compose.yaml and:

• find out the actual fully deployed configuration file to see all existing traefik. labels
• find the matching labels with their unique router ids for every domain that I've configured and want to have the redirect on
• create a custom middleware
• extend/add my newly created custom middleware to the matching router ids

And this all may break as soon as my container id changes or I add/remove a domain as all of this is happening in a completely different place than where I configure the redirects.

I'm not sure whether this is standard practise in Docker / Docker Compose to configure things like this as a label, but it feels utterly wrong and unnecessarily fragile from a UX standpoint. I know that I will break my own redirects in a couple of days when I forgot that I also need to configure/update them within my Docker Compose config.

Status Quo: Domains Configuration

As of v4.0.0 beta.400, a single text-input is used for configuring the domains of a service/app. That means that you can either enable GZIP for all domains, or none. The same applies to the "Strip Prefixes" option - all or none.

What about HTTP2 and HTTP3? Any other headers that your app might need, but you don't necessarily want to put within the app's code - which sometimes isn't even possible if you're hosting third-party code.

Need multiple values? Separate them by comma.

Actual Feature Request / Improvement

I'd like to request a proper domain configuration overhaul. That means that each domain is added as a dedicated entity/entry, and allows for per-domain configurations such as GZIP, Forced HTTPS, Redirect to www / non-www, and more. I'd really love to see a true HTTPS Passthrough from Traefik to Caddy, but this may be out of scope of this issue.

What we're gaining here is a more robust interface where less errors can occur since you don't need to rely on entering comma-separated values and get the ability for a more granular configuration of your services, all without touching the app's code.

Adding more domains or removing existing? No problem, since the configuration is now on a per-domain basis, you don't need to worry about affecting other changes, or accidentally breaking your redirects since you forgot to update a totally different place for that (The docker-compose.yaml)

Another benefit, although slightly less: This configuration is less Traefik-specific and could also be used for other proxy services.

What do you think? Anything worth pursuing? Is it just a skill issue on my side that I want a more robust UX/DX for setting basic things like this up?

[danielo515]

I am in a very similar situation.
I want to host a service that does not have authentication, so I need to put some reverse proxy on front. What was my surprise when I discovered that I can not configure several domains for a single service (for example authentik) and that there is no way to configure a reverse proxy details either for any service.
It is very disappointing. just like OP I don't want to mess with traefik tags again. I did that in the past and it's a nightmare, a recipe to disaster waiting for happening.