n8n 1.123.66 Fixes Code Node External Module Loading - What Production Teams Should Do Next
Release 1.123.66 of n8n patches a bug that prevented allowed external modules from loading in the Code node for 1.x users. This fix restores expected extensibility but also raises operational considerations around dependency management and security for production automation systems.
The 1.123.66 release resolves a practical blocker: the Code node was not honoring settings that permit external Node modules, which limited developers who rely on vetted NPM packages inside automated workflows. Restoring this capability is important because it allows reuse of mature libraries (parsers, SDKs, crypto utilities) and avoids replication of logic in ad hoc code snippets.
However, enabling external modules in an automation platform introduces new risks for enterprises. Bring-your-own-package increases attack surface (supply-chain vulnerabilities), complicates reproducibility, and can cause subtle runtime incompatibilities across versions of Node, container images, or the n8n runtime. For businesses running production automations, the fix is valuable only if accompanied by controls.
Recommended next steps: upgrade to 1.123.66 promptly in staging and run smoke tests for every critical workflow that uses external modules. Enforce dependency pinning (package-lock.json), prefer private registries or vetted package allowlists, and scan dependencies with SCA tools. Bake module approval into change control: require code reviews, test vectors, and runtime resource constraints for any workflow that imports external packages.
Operationalize these controls by delivering workflows as code artifacts (IaC or git-backed flows), embedding dependency checks in CI pipelines, and versioning container images for reproducible deployments. These practices let teams leverage the expressiveness of external modules while maintaining reliability and security at scale.
Original Source
n8n (GitHub)