Hi n8n community!
We upgraded our self-hosted n8n instance from 2.9.4 to 2.11.4 and n8n now fails to start with the following error:
Error: Failed to load module "community-packages": Cannot find module '/usr/local/lib/node_modules/n8n/dist/modules/community-packages.ee/community-packages.module'
Require stack:
- /usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+backend-common@file+packages+@n8n+backend-common/node_modules/@n8n/backend-common/dist/modules/module-registry.js
- /usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+backend-common@file+packages+@n8n+backend-common/node_modules/@n8n/backend-common/dist/index.js
- /usr/local/lib/node_modules/n8n/dist/config/index.js
- /usr/local/lib/node_modules/n8n/bin/n8n
Our current config includes:
n8n:
reinstall_missing_packages: true
enforce_settings_file_permissions: true
graceful_shutdown_timeout: 115
port: 5678
protocol: http
runners_enabled: true
runners_mode: external
runners_broker_listen_address: "0.0.0.0"
diagnostics_enabled: false
diagnostics_config_frontend: ""
diagnostics_config_backend: ""
version_notifications_enabled: false
hiring_banner_enabled: false
templates_enabled: false
metrics: true
editor_base_url: <redacted>
sso_saml_login_enabled: true
sso_saml_login_label: ''
disable_production_main_process: true
log_format: json
community_packages_enabled: true
unverified_packages_enabled: false
block_env_access_in_node: true
git_node_disable_bare_repos: true
skip_auth_on_oauth_callback: false
default_binary_data_mode: database
What we have already tried:
-
disabling reinstall_missing_packages
-
disabling community packages
-
restarting after config changes
The error still occurs.
What seems unusual is that n8n is attempting to load:
community-packages.ee/community-packages.module
but that module path does not exist in the installed package. This looks like it may be a packaging / module-registration regression or a mismatch in the installed artifact after the upgrade.
Could you advise:
-
whether this is a known issue in 2.11.4
-
whether there is a required cleanup step for global/npm-based installs before upgrading
-
whether this relates to enterprise/community package loading
-
whether you recommend a specific workaround besides reinstalling from scratch
We can also provide:
-
Node.js version
-
install method
-
container / host details
-
full startup logs
Thanks.
Hi @Marthinus_Strydom , hope you are doing well!
I’m not aware of this being documented as a known 2.11.4 issue, and that .ee path does make it look more like an install artifact / package mismatch than a normal config problem… If this was upgraded via global npm, I’d first confirm the install method and do a clean reinstall rather than an in-place overwrite, since n8n’s docs generally recommend Docker for cleaner, isolated upgrades in production. I’d also check whether any community packages are still registered and remove them with the n8n CLI if needed, because community packages are managed separately from core config flags. If you can share the install method, Node.js version, and full startup logs, that should make it much easier to tell whether this is a broken upgrade path or something enterprise-related being resolved incorrectly at startup.
Hi, thanks for the response - that’s helpful.
Just to clarify on our side: we are running n8n via the official Docker image, not a global npm install. So this shouldn’t be an in-place npm upgrade or leftover global package issue.
That’s why the .ee module path stood out to us. On startup, n8n is attempting to load:
/usr/local/lib/node_modules/n8n/dist/modules/community-packages.ee/community-packages.module
but that module doesn’t exist in the container image we upgraded to. Since this happens during module registration at startup, it seems like it may be happening before config flags (like disabling community packages) are applied.
For context:
-
Upgrade was 2.9.4 → 2.11.4
-
Running via Docker image
-
We’ve already tried disabling:
-
The error still occurs on startup
Thanks, that does help @Marthinus_Strydom , I agree this looks less like config and more like a bad image/state mismatch during startup, especially since disabling community packages should normally be possible via N8N_COMMUNITY_PACKAGES_ENABLED=false
In your place, I’d fully pull the exact target tag again, recreate the container from that image, and avoid reusing a floating tag, since n8n’s docs recommend pulling a specific version for Docker updates and pinning versions in production.
Because 2.11.4 is the current stable release, could you share the exact image tag you pulled and the full startup logs? That should make it much easier to tell whether the container image itself is inconsistent or whether something mounted into the container is interfering at boot.
Closing the loop here - thanks for the assistance.
It looks like our Datadog agent / APM instrumentation was interfering with the n8n runtime. During startup, the Datadog-injected instrumentation hooks were causing the crash.
After disabling a few modules, the underlying Datadog-related error became more visible. Once we fully disabled the Datadog agent, the pod stabilised and n8n started up without further issues.