Node-RED file logging lacks a documented retention boundary

Direct answer

Node-RED’s logging.file setting has no built-in retention boundary. The runtime does not cap file size, rotate logs, or truncate the file automatically; there is no undocumented behavior that bounds growth. The file grows until the filesystem is full or an external process intervenes. For a production instance where you are diagnosing repeated failed deployments, the recommended boundary is an external rotation policy—such as logrotate on a host or a container logging driver—that limits size or age and retains a small number of archives. This guidance assumes Node-RED 2.x or later.

Confirmed facts vs. likely assumptions

Confirmed: The documented properties for logging.file are limited to level and filename. There is no maxSize, maxFiles, or retention option in settings.js. The runtime appends indefinitely.

Likely explanation: The absence of a retention policy is not a missing feature in a particular Node-RED version; it reflects a design choice to delegate log lifecycle management to the host operating system or container runtime. Operators sometimes assume a hidden safety limit exists, but none is present in the core runtime.

Recommended boundary and steps

Because the goal is post-deployment failure analysis, the boundary should preserve enough contiguous history to span multiple deployment attempts while preventing disk exhaustion. A practical production boundary is rotation at roughly 100 MiB or daily, keeping five to seven archives. Adjust these values to match your deployment frequency and disk budget.

1. Reduce noise first. In settings.js, set logging.level to "error" or "warn". Deployment failures and missing-module errors are still captured, but verbose debug output is suppressed.
2. Configure host rotation. On a VM or bare-metal host, use logrotate with a size or time trigger. Because Node-RED does not document a signal to reopen its log file, use copytruncate or a postrotate script that recreates the file with the same owner and permissions so the process can continue writing.
3. Use container-native limits. If Node-RED runs in Docker, configure the json-file logging driver (or an equivalent) with max-size and max-file options. This bounds growth without modifying the container image.
4. Verify continuity. After rotation, confirm that the active file is writable and that the archived file contains the expected sequence of deployment failure entries.

Impact on log completeness

Without a retention policy, administrators often resort to manual truncation—for example, overwriting or deleting the file—which can destroy recent entries needed to correlate a failed deploy with its root cause. External rotation preserves a timestamped, contiguous archive. This allows you to reconstruct the exact order of events across restarts and repeated deployment attempts without risking the loss of the most recent diagnostic messages.