Different URL for Webhook in Cloudron
-
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!
-
Hello @firmansi
Currently, the N8N app is only supporting redirections as secondary domains.
Also, theWEBHOOK_URLis 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? -
Hello @firmansi
Currently, the N8N app is only supporting redirections as secondary domains.
Also, theWEBHOOK_URLis 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?@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
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login