Granular Environment Variable Access (Allowlist Array)

Feature Requests
, , , , ,
1

The idea is:

Introduce a new environment variable (e.g., N8N_ALLOWED_ENV_VARS_IN_EXPRESSIONS) that accepts a comma-separated array of strings. This would create an “allowlist” for environment variables. Currently, the variable N8N_BLOCK_ENV_ACCESS_IN_EXPRESSIONS is a boolean toggle that allows either “all or nothing” access. This new feature would allow only specific, pre-approved variables to be accessible within n8n expressions via the $env object.

My use case:

I want to allow my workflow builders to access non-sensitive environment variables - such as ENVIRONMENT_NAME (staging vs. production) or a specific SERVICE_BASE_URL - without exposing high-risk system variables like DB_PASSWORD, N8N_ENCRYPTION_KEY, or AWS_SECRET_ACCESS_KEY.

I think it would be beneficial to add this because:

It follows the principle of least privilege. In a team or multi-tenant environment, the current boolean toggle is too blunt; it forces admins to choose between breaking useful workflows or creating a massive security hole. Adding array-based filtering brings environment variable management in line with how n8n already handles node access (using NODES_INCLUDE and NODES_EXCLUDE), making the platform much more enterprise-ready.

Any resources to support this?

This behaviour would mirror the existing logic used for:

  • NODES_INCLUDE / NODES_EXCLUDE logic in the n8n docs.
  • Similar “allowlist” patterns found in other CI/CD and automation tools to prevent “secret leaking” in logs or UI expressions.

Are you willing to work on this?

I am happy to help test any beta implementations and provide feedback on the configuration UX.