Different URL for Webhook in Cloudron

[firmansi]

I want to set up my n8n instance on Cloudron so that the Webhook URL uses a different domain than the main dashboard instance URL.

For example:

• Main Instance/Dashboard: https://abc.n8n.com
• Webhook URL: https://xyz.n8n.com

I know that in a standard self-hosted Docker setup, we can achieve this by configuring the WEBHOOK_URL environment variable and routing both domains via a reverse proxy to the same container.

However, looking at the Cloudron dashboard, the "Change Location" settings only support HTTP Redirection to the primary domain. It does not seem to support a true Domain Alias (where both domains actively reverse-proxy into the same container web port simultaneously).

A standard 301/302 redirect will likely break incoming webhooks from third-party services.Given this limitation, what is the best workaround to achieve this in Cloudron?Is there a way to safely expose a second domain as an alias for the n8n app container?

Do I need to manually adjust the internal Nginx configuration via the terminal, or is there a way to leverage the CLOUDRON_ALIAS_DOMAINS env if I custom-package it?

Any guidance, workarounds, or examples from anyone who has done this would be highly appreciated. Thanks!

[james]

Hello @firmansi
Currently, the N8N app is only supporting redirections as secondary domains.
Also, the WEBHOOK_URL is set by the package at each start to the $CLOUDRON_APP_ORIGIN.

We would have to add this feature to the N8N app to allow full secondary locations.
Is this feature highly necessary for you or more a convenience?
Also can you give us some examples when this feature is needed?

[firmansi]

@james Yes, this feature is highly necessary for our use case rather than just a convenience.

To give you an example, it works similarly to Typebot, where the domain for development and backend management is kept separate from the public-facing chat interface.

We see a similar need in n8n. When we build public-facing features like n8n Chat or Forms, keeping them on the same domain as the workflow development console creates a major limitation. As long as they share the same URL on Cloudron, we cannot fully utilize these public features natively for our users; our only workaround right now is embedding them (as an iframe).

Having full secondary domain support would allow us to host the admin console on one domain while securely serving the public forms and chats on another

[james]

Hello @firmansi

Thank you for explaining.
I will look into this next week.

[firmansi]

@james Is there any ETA plan for this addition 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

[james]

Hello @firmansi
Some follow-up questions. Since this might be something we should solve on a platform level instead of specific to N8N.

How are sensitive web apps access protected these days?
VPN, Firewall, Proxy?

With Cloudron 10 VPN protection for apps is introduced.
I just tested that with N8N and multiDomain and N8N_WEBHOOK_URL.
When VPN protection is enabled for the N8N app you can only access N8N with the VPN and also post to a webhook node only works when connected to the VPN.

What if we'd make it possible to configure VPN protection more precisely?
For example protecting domains, subdomains, aliases from an app individually.
This way with the N8N example, the main domain could be protected by VPN and the webhook alias not.
A POST against the webhook alias would go through but when visiting the alias it redirects to the main domain which is then protected by the VPN and displays you need a VPN.
This feature could be expanded even more in depth like protecting certain paths from an app.
One example I could think of is the WordPress login page, that could then be protected by the VPN.

Do you people have thoughts on that?

---

On another topic with N8N and N8N_WEBHOOK_URL.
Wildcard domains are actually working.
You could configure e.g.: *.webhook.cloudron.dev and webhook.cloudron.dev as an alias for the N8N app and then set:

export N8N_WEBHOOK_URL="https://webhook.cloudron.dev/"

Then you can do stuff like:

curl -sk -X POST "https://that-is-one-random-subdomain.webhook.cloudron.dev/webhook-test/b419e0e2-d7df-4c57-9750-37d6a2074b9c" \
  -H "Content-Type: application/json" \
  -d '{"IsCloudronAwesome": true}'
{"message":"Workflow was started"}