App stopped responding after updating package to v4.24.0

[dev-cb]

@james said:

Hello @dev-cb
Where did n8n-nodes-xlsx come from, with your statement:

@dev-cb said:

/app/data/user/.n8n/nodes/node_modules/n8n-nodes-xlsx/

This was not in the log you posted above, so how did you figure out it was this folder?

Copied the wrong event. My bad... Sorry for sloppiness.
I’ve adjusted the post with the log.

[luckow]

@dev-cb I had the same issue with an empty Zabbix folder. Restoring the old version, deleting the empty folder, and updating to the latest version worked. But I thought it had nothing to do with the app package and was just an issue with my instance.

[dev-cb]

@luckow said:

@dev-cb I had the same issue with an empty Zabbix folder. Restoring the old version, deleting the empty folder, and updating to the latest version worked. But I thought it had nothing to do with the app package and was just an issue with my instance.

Yes. Just did the same, backup, update, restart went all though.

[james]

I have looked into this issue.

#1 Our EXTRA_NODE_MODULES (for the Code node) installed in start.sh:47-50 into /run/n8n/custom-node-modules/, which is ephemeral (/run/...) and reinstalled on every boot, then symlinked to /app/node_modules (Dockerfile:40).

#2 n8n Community Nodes (n8n-nodes-*, installed through the web UI), n8n puts these under $N8N_USER_FOLDER/.n8n/nodes/, i.e. /app/data/user/.n8n/nodes/. That's persistent (under /app/data). It keeps a package.json listing the installed community packages plus the actual code in nodes/node_modules/, and also tracks them in the DB.

The failing path is /app/data/user/.n8n/nodes/node_modules/n8n-nodes-xlsx/package.json, that's path #2. n8n-nodes-xlsx is a community node the user installed via the UI. The crash (scanDirectoryForPackages → CommunityPackagesModule.nodeLoaders) happens because the nodes/package.json still lists n8n-nodes-xlsx but the actual node_modules/n8n-nodes-xlsx/ directory is missing/incomplete, an orphaned reference. n8n's startup scan is not tolerant of this and throws.

Typical cause: a community-node install/uninstall that was interrupted or partially failed (npm wrote the package.json entry, but the module folder wasn't fully written), or the directory got out of sync across a restart/upgrade. It's a n8n-side robustness issue, not our packaging.

We could add a handler in our start.sh to prevent this issue.
I will look into that.

[ChrisHvd]

@dev-cb I cannot update my instance and try as prod workflows are running. But I have another instance which migrated to 2.24.0 without any trouble. The only difference between the two is the presence of NODE_FUNCTION_ALLOW_BUILTIN=* on the first one (the one that crashes).

[james]

Hello @chrishvd
Please check the start log when you have updated N8N and send that log.
If the log includes lines like the above issue from a n8n community node, you can fix the issue like mentioned by @dev-cb

[ChrisHvd]

The only thing I can found is slightly different from yours, although it touches some n8n node package I don't know.

*2026-05-26T00:01:05Z ⠼==> Starting N8N
2026-05-26T00:01:08Z Last session crashed
2026-05-26T00:01:10.000Z => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.212:5678
2026-05-26T00:01:18Z 
2026-05-26T00:01:18Z 
2026-05-26T00:01:18Z Node loader n8n-nodes-base is already registered.
2026-05-26T00:01:18Z Error: Node loader n8n-nodes-base is already registered.
2026-05-26T00:01:18Z Error: Node loader n8n-nodes-base is already registered.
2026-05-26T00:01:18Z Error: Exiting due to an error.*

[james]

Hello @chrishvd
This looks indeed different.
And there is no log after texiting due to an error?

[ChrisHvd]

nope, nothing more than what I showed you. Here is the full log (quite short...), the server loops on this over and over.

2026-05-26T00:00:10.000Z => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.212:5678
2026-05-26T00:00:12Z 
2026-05-26T00:00:12Z 
2026-05-26T00:00:12Z Node loader n8n-nodes-base is already registered.
2026-05-26T00:00:12Z Error: Node loader n8n-nodes-base is already registered.
2026-05-26T00:00:12Z Error: Node loader n8n-nodes-base is already registered.
2026-05-26T00:00:12Z Error: Exiting due to an error.
2026-05-26T00:00:12Z Exiting due to an error.
2026-05-26T00:00:12Z Initializing n8n process
2026-05-26T00:00:12Z at /app/code/bin/n8n:63:2
2026-05-26T00:00:12Z at /app/code/bin/n8n:63:2
2026-05-26T00:00:12Z at /app/code/bin/n8n:63:2
2026-05-26T00:00:12Z at CommandRegistry.execute (/app/code/src/command-registry.ts:82:4)
2026-05-26T00:00:12Z at CommandRegistry.execute (/app/code/src/command-registry.ts:82:4)
2026-05-26T00:00:12Z at CommandRegistry.execute (/app/code/src/command-registry.ts:86:25)
2026-05-26T00:00:12Z at LoadNodesAndCredentials.init (/app/code/src/load-nodes-and-credentials.ts:111:11)
2026-05-26T00:00:12Z at LoadNodesAndCredentials.init (/app/code/src/load-nodes-and-credentials.ts:111:11)
2026-05-26T00:00:12Z at Start.catch (/app/code/src/commands/start.ts:435:14)
2026-05-26T00:00:12Z at Start.exitWithCrash (/app/code/src/commands/base-command.ts:231:28)
2026-05-26T00:00:12Z at Start.init (/app/code/src/commands/base-command.ts:124:3)
2026-05-26T00:00:12Z at Start.init (/app/code/src/commands/base-command.ts:124:3)
2026-05-26T00:00:12Z at Start.init (/app/code/src/commands/start.ts:211:3)
2026-05-26T00:00:12Z at Start.init (/app/code/src/commands/start.ts:211:3)
2026-05-26T00:00:15Z ==> Ensure directories
2026-05-26T00:00:15Z ==> Setting permissions
2026-05-26T00:00:15Z => Installing https@1.0.0
2026-05-26T00:00:16Z found 0 vulnerabilities
2026-05-26T00:00:16Z up to date, audited 2 packages in 507ms
2026-05-26T00:00:16Z ⠙⠹⠸⠼
2026-05-26T00:00:16Z ⠼
2026-05-26T00:00:16Z ⠼==> Starting N8N
2026-05-26T00:00:19Z Last session crashed
2026-05-26T00:00:20.000Z => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.212:5678
2026-05-26T00:00:29Z

[james]

Hello @chrishvd
How much memory did you give this N8N?
Perhaps it is not enough and a simple increase could resolve the issue.

[ChrisHvd]

8Gb for this instance, more than enough, especially knowing that nothing has changed in terms of workflows and stuffs. The 4.23.x is stable though.