@james safe as in I want to avoid corruption this is way I pick database number 1 because if; Redis is shared between all the container and attribute different database to each of them then if manually I use a database number (such as 1) I might shoot data and disrupt one of my services. PS: I don't really know Redis but I presume, as in any database, data integrity is important.

Hello @Valexico This is something we would have to look into.

@umnz I have asked here - https://community.n8n.io/t/track-github-or-npm-for-stable-releases/197205

Hello @alexftth and welcome to the Cloudron forum Some questions so we can bet a better picture. Did any app updates happen in the timeframe of this issue arising Did you restart the server since then? If no, please restart the server once When restarted, please ssh into your server and as root run: cloudron-support --troubleshoot Check if it is working now. If not, share the output of this command and also run: cloudron-support --send-diagnostics This will generate a URL with details about your server, share this URL with us here as well. (this also includes IPs and DNS names, if you don't wish to post this publicly, send this with a DM to me) Also re-run the commands you used inside the container and run them from root.

Thanks for the feedback @zonzonzon We could use more feedback from heavy users of N8N to determine if the redis change truly was helpful.

It is not unusual that the memory usage for a service like postgres is filled up. Generally if memory is available it is good to be utilized, however since a database engine doesn't know what else is on the system, we have that limit, otherwise it might just use up everything for caching.

@firmansi latest version was pushed to Cloudron

Hello @JueBam Sometimes, it can be that simple. Good to read, that it is now working for you.

May I know what is the impact of this issue?

Thanks for the heads up, once the n8n release is marked as stable, we will push out the package.

@girish Thanks for your explanation, I will add version within the The appStoreId, @james so now I have something pretty robust and will use the following process: All updates disabled by default I will manually check and update Cloudron quarterly, on specific timeframes I will leverage on API to orchestrate each app upgrade individually

NM, I just read the docs and it says production doesn't display data like with test. It's in the executions only. https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/?utm_source=n8n_app&utm_medium=node_settings_modal-credential_link&utm_campaign=n8n-nodes-base.webhook#webhook-urls

Just chiming in here because I ran into a CORS error as well. Solution was not a missing env var, it was activating the workflow - because without that, the URL didn't exist yet and threw the various errors.

Any updates on the Cloudron 9 update?

I posted this in the evening and in bed that night I remembered that I hadn't even looked at the documentary (where it was demonstrably described) - no joke. Regarding your question: It might have helped if somewhere when creating the post - especionally in the support section (preferably BEFORE you hit the big send button), there had been another note about whether you had already looked at the documentation.

Hello @arta you can use the n8n cli to reset all users. See: https://docs.n8n.io/hosting/cli-commands/#user-management You can reset user management using the n8n CLI. This returns user management to its pre-setup state. It removes all user accounts. Use this if you forget your password, and don't have SMTP set up to do password resets by email. Go into the Cloudron n8n web terminal and run: gosu cloudron /app/code/node_modules/.bin/n8n user-management:reset Hope this solves your problem

@luckow thanks for reporting, I think https://git.cloudron.io/packages/n8n-app/-/merge_requests/64 should fix it

I just found the reason, a bad setting in my env.sh file which prevented the normal functioning of the code nodes. Regards

Yes, I've been doing this for years, you just have to make /app/data friendly enough for apps to find what they need. This generally involves setting a few env variables: HOME PATH (including NODE_PATH avoiding npm i -g) LD_LIBRARY_PATH (less common) other app specific ENVs All of these changes do not affect the running app since it's already running with its own ENVs. So these are great for additional services. Nice work @djxx