[Enhancement]: Improved domain configuration for allowing "www to non-www" / "non-www to www "redirects #5491
Replies: 2 comments
-
|
I am in a very similar situation. |
Beta Was this translation helpful? Give feedback.
-
|
This is needed. I just started using Coolify, and I used to host the sites on Netlify. And on Netlify I could just add a _redirects file that would handle it for me. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.yamland:traefik.labelsAnd 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?
Beta Was this translation helpful? Give feedback.
All reactions