Persistent Webhook url

When I’m running locally and testing with webhooks, I have to use --tunnel. Sometimes the process seems to get stalled or slow to the point of not updating, so I’ll restart with n8n start --tunnel, which resets the webhook address. For things like Trello, this isn’t an issue as those webhooks are generated dynamically, but some of the services I interact with require a webhook address to send to and are not as dynamic. If I have to restart n8n, is it possible to make sure the webhook url is persistent?
I’ve been wondering if using something like pm2 to manage n8n is possible, or if that could prevent the process from becoming stale. Any tips?

The webhook URL will only change if you do persists the .n8n folder as that is where the webhook URL gets saved. Not persisting this folder will definitely cause problems. Especially will it also result in you not being able to decrypt your credentials after a restart.

You can find the topic of somebody else which had the same problem here:

Apart from that did “sadly” never hear before that n8n becomes stale. I also never experienced it myself. So no idea why that happens for you.

I guess I am confused because that folder exists for me, but the ‘config’ file inside it shows a different tunnel subdomain than what is shown when I run n8n start --tunnel. In fact, it shows a subdomain that was at one point functional, but not anymore. Is that key/value pair supposed to be updated on each restart of n8n?

No. On startup, it checks if the file exists and if not it creates it. On the first start it will then output something like that:

UserSettings got generated and saved to: /root/.n8n/config

If the file exists already it will simply read its data and will not touch it at all.

So something must be wrong/strange in your setup. Either it uses a different config file (maybe n8n starts as a different user than you expect), there are some access-right issues and it can not read/write (but then I would expect some kind of error message), or something else.

So the file was last updated November 1st, but clearly n8n is still using the database file in this folder, so it should be reading this config file as well. Where would another version of this config file be? This one is in ~/.n8n/

-rw-r--r--@  1 wigoode  139277742   104B Nov  1 12:19 config
-rw-r--r--@  1 wigoode  139277742    15M Nov  7 16:24 database.sqlite

Honestly no idea. The location sounds correct. Also the last updated date would make sense as once created it normally does never get changed. The only temp fix I can think of right now would be to set them via environment variables as described in the topic linked above.

Well, it was working via environment variables last night, but it is now ignoring N8N_TUNNEL_SUBDOMAIN and creating a new tunnel URL on each restart. Even weirder, it picks up the N8N_BASIC_AUTH environment variables and uses those. While the server was technically still running this morning, the custom subdomain I set returned a 504 error, indicating it was unable to find the server. Anything else I should try?

No, I am very sorry but everything you describe just puzzles me. I have never experienced anything which comes even remotely close to what you are describing. How is your setup? What OS are you using, what Node.js and what n8n version?

Can you maybe simply run n8n with docker-compose? There is a tutorial here:

There it describes step by step what has to be done and if you follow that n8n should run perfectly fine afterwards.

Here is my setup:
Node 12.10.0
n8n 0.34.0
28%20AM
I’ll try it with docker (running locally at least) and report back after a day or so.

Ah, you are mac user. It should theoretically not be a problem but is however still possible. Running it in Docker is probably the most secure in that case.

Well Jan, it looks like your code may be blameless here haha. I found this issue (and a bunch like it) on the localtunnel github. `--subdomain` option does not always work · Issue #248 · localtunnel/localtunnel · GitHub

Looks like localtunnel doesn’t kill processes reliably, leading to a zombie that blocks usage of the same subdomain. Really unfortunate, but I guess I ought to set up a server that’s not just my work laptop.