Node-RED file logging lacks a documented retention boundary

Node-RED's logging.file option in settings.js directs runtime deployment failures, missing module errors, and flow validation messages to a persistent file, which is useful for headless or containerized environments where the editor console is unavailable. The documented properties for this object are limited to level and filename; there is no core setting for maximum file size, backup count, or automatic truncation.

Because rotation is absent, the log file grows monotonically until the filesystem or an external process intervenes. Long-running instances or verbose levels such as debug can accelerate growth, complicating inspection and increasing disk usage without warning. Operators must therefore decide whether to accept unbounded growth, rely on external log rotation, or periodically truncate the file manually.

What is the recommended boundary for logging.file retention when diagnosing repeated failed deployments in a production Node-RED instance? Should administrators configure an external rotation tool, or is there an undocumented runtime behavior that bounds file growth? How does the absence of a retention policy affect log completeness during post-deployment failure analysis?