Different URL for Webhook in Cloudron

[james]

Hello @firmansi
Unfortunately I can't give you a reliable ETA.
I might be able to look into this the coming week, but I can't promise anything.

[firmansi]

@james is there any plan to implement this?

[robi]

@firmansi can you work around as a second n8n instance or another webhook provider?

[james]

Hello @firmansi
Sorry for the delay.
The Cloudron 10 release currently takes priority over new app features.

[firmansi]

@robi What do you mean another webhook provider?

[robi]

@firmansi like nocodb, it's a separate url, as another n8n instance would be as well.

[andreasdueren]

@james @girish Out of curiosity I checked the current n8n package and this appears to be a small package-only change to satisfy @firmansi neeys. No Cloudron platform or custom nginx changes are required.

The implementation could be as simple as:

• Add "multiDomain": true to CloudronManifest.json
• Set N8N_EDITOR_BASE_URL to the primary CLOUDRON_APP_ORIGIN
• Let users select an alias with N8N_WEBHOOK_URL in /app/data/env.sh
• Preserve existing legacy WEBHOOK_URL overrides

One limitation: an alias exposes the whole n8n app, not only webhook paths. It nevertheless provides the requested separate canonical domain for forms, chat, and generated webhook URLs.

I can attach the ready patch here if helpful.

[james]

Hello @andreasdueren
Thanks for the input.
I have tested this and what you have stated is indeed correct.

So yes we can add this feature, but the alias will still redirect to n8n itself.
If that is okay, I can create an app update for N8N.

[james]

Hello @firmansi
Can I take your upvote as confirmation that this behaviour is acceptable?

[firmansi]

@james that means the alias domain still can expose main login domain for example my n8n domain is abc.domain.com and the alias domain is xyz.domain.com then if someone point to xyz.domain.com then it still can open n8n login directly too?

[andreasdueren]

@firmansi Correct

[firmansi]

@andreasdueren well, i think that's not what i expect LOL, it's still unsecured

[james]

Hello @firmansi

@firmansi said:

it's still unsecured

I think unsecured is a bit unproportioned, unless you N8N somehow has no login validation.
But I still understand your point being that you wish for the subdomain to not redirect to the main N8N.
I will have to think about this if that is somehow possible.

[firmansi]

@james ya, i can still secure it using proxy that will lock away user accesing UI login from main sub domain