Custom Runner Images and Allowlisted npm Packages: Expected Behavior and Recommendations

Executive takeaway: Security policies (allowlists) and runtime environments (custom runner images) are orthogonal concerns: allowlisting says which packages are permitted, while resolution requires the packages to be present in the execution environment. Platforms should make this separation explicit and provide configuration to reconcile them.

When a task runner enforces allowedExternalModules but the container image lacks the package, the system correctly prevents unauthorized modules but then fails at resolution. That behavior is logically consistent, but the error messaging ("Module is disallowed" → "Cannot find module") can be confusing. The platform should clarify whether allowlisting implies preinstallation or merely runtime permission. There are three defensible approaches: (1) require preinstalled packages in the runner image, (2) provide an image build-time hook to inject allowlisted packages, or (3) support secure on-demand installation with strict auditing.

For engineering teams using n8n or similar automation platforms: standardize custom runner images in your CI pipeline and include commonly used allowlisted packages to avoid runtime surprises. Add validation tests that run sample workflows against runner images before deployment. Document which packages are permitted and which images include them to align developer expectations.

For product leaders and platform maintainers: improve developer ergonomics by enhancing error messages, documenting the resolution model, and offering tooling (Dockerfile snippets, a package manifest) that automates building runner images with the approved package set. Consider an opt-in "resolve from host" toggle only for trusted environments, bounded by audit logs and image immutability.