Ghost Logging: File Transport with Rotation vs. Stdout for Docker

When configuring a Ghost production environment, specifically within Docker or systemd-managed instances, there is a design choice regarding how application logs are captured and retained for post-deployment diagnostics.

Ghost supports internal logging via the config.production.json file, allowing for a path to the content/logs directory with built-in rotation. Alternatively, configuring the transport to stdout delegates log management to the container runtime or journald.

Constraints and Trade-offs

• File Transport: Provides bounded on-disk history managed by Ghost, but requires persistent volume mapping in Docker to avoid data loss during container restarts.
• Stdout Transport: Simplifies integration with external log aggregators and docker logs, but removes Ghost's internal rotation logic, shifting the burden of retention to the host OS or container driver.

A critical uncertainty arises during startup failures: errors occurring before the logger initializes may only appear in stderr, potentially creating gaps if only file transports are configured.

Should the logging configuration prioritize Ghost's internal rotation for self-contained post-mortems, or rely exclusively on stdout to leverage host-level rotation tools? Is there a documented risk of duplicate entries or truncated logs when enabling both transports simultaneously?