App stopped responding after updating package to v4.24.0

[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.