Several Documentation Errors

I have identified a few documentation issues which are set out below. It is difficult to address the same topic in multiple places which can lead to inadequate and inaccurate documentation. It would be better if the environment variables compilation page references the pages that cover the various sections in more detail.

Logging

N8N_LOG_FILE_LOCATION

The description is inconsistent on these two pages:

Default is <n8nFolderPath>/logs/n8n.log
Default is file

DB_LOGGING_OPTIONS

It would be helpful if there was a better description as to the effect of each option. The word log as a value for logging options does not provide much clarity.

To provide greater clarity, it would be helpful to transition to the variable name DB_LOG_LEVEL. A quick search suggests that this would not create a conflict with another environment variable. Aside from being shorter, this would make the variable consistent with the naming convention used for N8N_LOG_LEVEL and also be more descriptive. A phased migration should avoid user inconvenience.

The list of available DB_LOGGING_OPTIONS seems to go from highest to lowest (i.e., query to log) whereas N8N_LOG_LEVEL goes from lowest to highest (i.e., info to debug). The lowest to highest approach is the most intuitive.

Deployment

N8N_PUBLIC_API_DISABLED

The name suggests that the value should be true if the API is disabled. The description says the opposite: “Whether to disable the public API (false) or not (true).” and appears to be contrary to the following: n8n/packages/cli/scripts/build.mjs at master · n8n-io/n8n (github.com)

N8N_PUSH_BACKEND

It would be helpful to explain the difference between sse and websocket and why websocket is preferred.

Workflows

N8N_ONBOARDING_FLOW_DISABLED

The name suggests that the value should be true if it is disabled. The description says the opposite: “Whether to show onboarding tips when creating a new workflow (true) or not (false).”

Binary Data

N8N_BINARY_DATA_STORAGE_PATH

There appears to be a typo in the Default column. The value should be N8N_USER_FOLDER/binaryData.

I also could not find N8N_USER_FOLDER in the environment variables within the Docker container.

Security Audit

The link in the Nodes section to Audit constants returns a 404 error. This is the correct link.

Public API Reference

Execution: Retrieve an execution

Should be “Retrieve an execution from your instance.”

Spelling

There are two instances on the Environment variables reference page of “separated” being spelled as “seperated”. See N8N_AUTH_EXCLUDE_ENDPOINTS and N8N_LOG_OUTPUT.

Enum String Ambiguity

It would be helpful to explain, by tooltip or otherwise, if it is possible to specify multiple values. The Environment variables reference has eight instances of Enum string as possible options however the usage is unclear.

For DB_LOGGING_OPTIONS, the possibility of specifying all suggests that it might be possible to set the value to info, warn

For N8N_LOG_OUTPUT, it seems to be logically possible to output a log to both console and file. This is supported by the description “Provide multiple values as a comma-seperated list.”

Specifying multiple values for enum seems to be unusual and improper. The other enum options appear to only allow one value to be specified. For example, EXECUTIONS_DATA_SAVE_ON_ERROR can only be all or none.

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Further to this, there is another discrepancy:

Is it N8N_LOG_FILE_MAXCOUNT or N8N_LOG_FILE_COUNT_MAX?

The documentation on the above two pages is also missing the silent option.

As a further refinement, the DB_LOGGING_ENABLED variable could be eliminated and replaced with a none option in DB_LOGGING_OPTIONS.

Hi! Commenting here as well for visibility: Thanks for the detailed feedback. I’ve assigned myself to the GitHub issue you raised. I’ll follow up over on GitHub for any further discussion.

2 Likes

Thank you, @deborah, for so quickly attending to this.

I will add any more observations that I may have to this thread.

I have a few more suggestions for potential enhancements:

Environment variables reference

The _FILE instructions at the top of the page are easily overlooked or forgotten given the length of the page. They also do not include an example. A tooltip for each instance would be helpful. Additionally, or in the alternative, it would be clearer if the variable was presented as follows:

CREDENTIALS_OVERWRITE_DATA or CREDENTIALS_OVERWRITE_DATA_FILE

It is still not clear with the given instructions how this should be handled. For example, the following questions might be asked:

  1. Do I have to create a separate file for each variable or can I use a single file for all such variables?
  2. What do I enter for the value? For example, according to the table, the DB_POSTGRESDB_PORT_FILE type is number and the default is 5432. It is unclear whether the user is supposed to provide the name and path of a file or leave it empty. Adding the port number does not make sense nor is the name and path of a file a numeric value. The relationship to N8N_CONFIG_FILES is not obvious.

Configuration methods

The Set environment variables using a file section answers the foregoing questions however the answer is not near the top of the page and is easily overlooked.

The Keeping sensitive data in separate files section could include links to the following:

A note that Docker secrets are only available with Docker Swarm would be helpful.

It is possible that some users could understand this section to mean that the _FILE approach is only available with Docker secrets or Kubernetes Secrets.

The list of environment variables that support _FILE is not intuitive. I suggest the following order:

  • CREDENTIALS_OVERWRITE_DATA_FILE
  • DB_TYPE_FILE
  • DB_POSTGRESDB_HOST_FILE
  • DB_POSTGRESDB_PORT_FILE
  • DB_POSTGRESDB_USER_FILE
  • DB_POSTGRESDB_PASSWORD_FILE
  • DB_POSTGRESDB_DATABASE_FILE
  • DB_POSTGRESDB_SCHEMA_FILE
  • DB_POSTGRESDB_SSL_CA_FILE
  • DB_POSTGRESDB_SSL_CERT_FILE
  • DB_POSTGRESDB_SSL_KEY_FILE
  • DB_POSTGRESDB_SSL_REJECT_UNAUTHORIZED_FILE

VUE_APP_URL_BASE_API

For this variable, the Environment variables reference page should reference this, more detailed, explanation: Configure the Base URL for n8n’s front end access | n8n Docs

Persisting Binary Data

There are fairly recent posts referencing N8N_BINARY_DATA_TTL and N8N_PERSISTED_BINARY_DATA_TTL however these variables are not listed.

These variables have since been deprecated. “Instead of relying on a TTL system for binary data, n8n currently cleans up binary data together with executions during pruning.”

I have not, however, found an explanation in the documentation of this approach to keeping the size of the binary data directory in check. The following pages/sections could benefit from an explanation:

The following limitation should also be more clearly communicated:

External storage for binary data | n8n Docs: “Binary data pruning operates on the active binary data mode. For example, if your instance stored data in S3, and you later switched to filesystem mode, n8n only prunes binary data in the filesystem. This may change in future.”

Queue Mode - Start Redis

QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD

This page says that the default value for QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD is 10000ms.

Environment variables reference - Queue Mode says that this value has to be a number and lists the default as 10000. This page also describes the timeout as being in “seconds” when it should clearly be “milliseconds”.

QUEUE_WORKER_TIMEOUT

Queue Mode - Start Redis still lists QUEUE_WORKER_TIMEOUT. This has been deprecated in favour of N8N_GRACEFUL_SHUTDOWN_TIMEOUT.

Omitted Environment Variables

The following environment variables are not listed on this page but are listed in Configuration environment variables - Queue mode:

  • QUEUE_BULL_PREFIX
  • QUEUE_BULL_REDIS_CLUSTER_NODES
  • QUEUE_BULL_REDIS_TLS
  • QUEUE_HEALTH_CHECK_ACTIVE
  • QUEUE_HEALTH_CHECK_PORT
  • QUEUE_WORKER_LOCK_DURATION
  • QUEUE_WORKER_LOCK_RENEW_TIME
  • QUEUE_WORKER_STALLED_INTERVAL
  • QUEUE_WORKER_MAX_STALLED_COUNT

Since this page appears to cover deployment in queue mode in great details, it is unclear if the above environment variables have been deprecated and, if not, how they should be used.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.